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Executive  Summary 


Through  thermal  emission  and  scattered  solar  radiation,  clouds  present  a  significant 
clutter  source  to  infrared  surveillance  sensors  viewing  from  space.  To  simulate  these  effects 
for  the  defense  community,  Photon  Research  Associates  (PRA)  has  developed  CLDSIM. 
This  program  has  been  used  to  generate  cloud  background  scenes  both  as  a  stand-alone 
code  and  as  a  part  of  the  Strategic  Scene  Generation  Model  (SSGM).  Since  the  SSGM  is 
gaining  acceptance  as  a  standard  source  of  background  radiance  scenes  for  defense 
simulations,  it  is  important  to  review  CLDSIM  to  understand  what  it  does  and  how  it  can  be 
improved. 

This  report  presents  an  independent  review  of  CLDSIM  undertaken  by  Visidyne,  Inc. 
To  accomplish  its  task,  Visidyne  has  generated  cloud  images  with  CLDSIM;  inspected 
available  documentation,  briefings  and  validation  reports;  read  through  the  code;  and  had 
several  discussions  with  PRA.  The  discussions  focused  on  the  current  operation  of  CLDSIM 
and  future  development  plans. 

Chapter  1  of  the  report  gives  a  brief  overview  of  CLDSIM  code  and  of  the  databases 
that  it  requires  to  operate.  Chapter  2  reviews  each  of  CLDSIM's  components  in  turn.  A 
description  of  each  component  is  followed  by  a  critique  with  recommended  changes.  A  list 
of  PRA's  planned  changes  is  also  given.  Chapter  3  describes  the  MSLAB  code  that  Visidyne 
developed  to  calculate  scattering  off  of  clouds.  This  code  is  used  to  investigate  the  limits  of 
CLDSIM's  treatment  of  this  process.  Chapter  4  presents  a  calculation  of  the  effects  of  line 
correlations  between  gaseous  absorbers  in  the  cloud  and  in  the  surrounding  atmosphere. 
This  calculation  provides  an  explanation  of  a  factor  of  three  difference  between  CLDSIM's 
calculations  and  data  in  an  absorbing  region.  Chapter  5  provides  a  table  listing 
recommended  improvements  to  CLDSIM.  Chapter  6  concludes  with  a  list  of  references. 

CLDSIM  Version 


The  term  CLDSIM  properly  refers  to  a  specific  PRA  proprietary  code  that  calculates 
cloud  radiances  that  are  displayed  as  a  scene  viewed  from  a  sensor's  perspective.  Over 
time,  the  term  has  come  to  represent,  first,  a  collection  of  PRA  stand-alone  codes  that 
perform  a  range  of  auxilliary  functions  necessary  to  prepare  inputs  for  CLDSIM  proper,  and 
second,  the  SSGM  implementation  of  these  codes.  The  stand-alone  codes  and  the  SSGM 
implementation  differ  enough  that  PRA  calls  the  latter  SSGM  CLOUD  /  HORIZON.  The 
SSGM  implementation  differs  from  the  stand-alone  version  by  being  about  one  release 
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behind  the  stand-alone  code,  by  having  a  few  parameters  hardwired,  and  by  having  fewer 
databases  to  access.  Visidyne  reviewed  SSGM  CLOUD  /  HORIZON  Release  5.1. 
Throughout  most  of  this  report,  it  is  simply  called  CLDSIM,  because  that  is  the  more  general 
name  used  in  the  defense  community,  and  because  many  of  the  comments  made  about  the 
SSGM  implementation  pertain  as  well  to  the  stand-alone  version  of  the  code  corresponding 
to  Release  5.1.  Lists  of  databases  and  BRDFs  given  below  should  not  be  taken  as 
limitations  on  the  number  available.  New  capabilities  of  the  stand-alone  code  can  be  inferred 
from  the  descriptions  of  PRA's  plans  for  Release  6.0  and  beyond. 

CLDSIM  Operation 

CLDSIM  models  infrared  cloud  radiances  by  combining  blackbody  thermal  emissions 
at  cloud  altitude  with  solar  radiation  scattered  from  the  cloud's  top  surface.  To  perform  its 
calculations,  CLDSIM  requires 

(1 )  Databases  of  cloud  top  altitudes  to  determine  the  temperature  at  which  the  cloud 
top  radiates,  as  well  as  descriptions  of  the  scattering  properties  of  the  cloud  droplets. 

(2)  Databases  of  Bidirectional  Reflectance  Distribution  Functions  (BRDFs)  which 
determine  the  magnitude  and  direction  of  light  scattered  off  of  the  cloud  surface. 

(3)  APART  radiation  transport  code  calculations  of  the  spectral  solar  irradiance,  path 
radiance,  and  skyshine  observed  by  a  sensor. 

CLDSIM  operates  by  looping  over  the  pixels  of  a  cloud  database,  determining  altitudes 
and  calculating  scattering  geometries.  The  APART  radiances  are  interpolated  over  altitude, 
and  over  bounding  solar  and  observer  positions.  The  interpolated  temperature  of  the  cloud 
top  as  well  as  the  interpolated  cloud  emissivity  are  used  to  calculate  the  cloud's  thermal 
emission,  while  the  BRDF  and  solar  irradiance  determine  the  solar  scattered  radiance.  Path 
radiance,  skyshine,  and  transmitted  radiance  from  the  underlying  terrain  are  also  include. 

Databases 


In  SSGM  Release  5.1 ,  CLDSIM  is  supplied  with  a  set  of  seventeen  cloud  top  altitude 
databases  to  use  in  simulations.  These  are  generated  from  such  sources  as  NOAA  satellite 
multispectral  infrared  data.  Cloud  altitudes  are  computed  by  assuming  that  the  cloud  surface 
radiates  as  a  blackbody  at  the  local  atmospheric  temperature.  The  apparent  brightness 
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values  from  cloud  images  are  thus  converted  into  local  temperatures,  while  atmospheric 
profiles  obtained  from  coincident  sounding  measurements  provide  a  means  to  convert  from 
temperature  to  altitude.  Altitude  thresholds  and  visual  inspection  of  the  data  are  used  to  type 
the  observed  clouds  as  being  either  altostratus  with  4  km  base,  altostratus  with  6km  base, 
cumulonimbus,  or  cirrus. 

Only  clouds  represented  in  one  of  CLDSIM's  cloud  altitude  databases  can  be  included 
in  a  CLDSIM  simulation.  Therefore,  it  is  important  to  know  how  representative  these 
databases  are,  both  in  terms  of  the  types  of  clouds  represented,  and  in  the  range  of 
radiances  that  CLDSIM  predicts  from  them.  The  databases  generally  have  been  created  at 
the  request  of  one  of  several  project  offices  that  has  chosen  a  particular  scenario  to  run  over 
a  particular  location.  PRA  has  then  been  tasked  to  inspect  the  available  data  and  to  create 
cloud  altitude  databases  that  are  representative  of  stressing  cloud  conditions  for  the 
scenario.  One  can  thus  say  that  CLDSIM  covers  the  range  of  clouds  for  the  particular 
locations  of  these  scenarios.  To  broaden  the  range  of  clouds  available  to  the  general  user, 
PRA  has  added  several  new  databases  over  the  past  few  years.  There  is  presently  no 
metric  to  confirm  that  a  spanning  set  of  cloud  types  has  been  obtained,  or  that  the  CLDSIM 
cloud  returns  span  the  range  of  returns  observed  by  sensors.  Extensive  data  from  a  platform 
such  as  DSP  would  be  needed  to  generate  such  a  metric. 

Users  desire  CLDSIM  databases  that  have  both  high  spatial  resolution  and  wide 
coverage.  These  two  requirements  are  often  in  conflict.  Many  of  CLDSIM's  databases  have 
been  created  using  the  wide  coverage  of  NOAA  satellites.  These  databases  come  from  data 
with  the  moderate  resolution  of  1.1  km.  To  obtain  higher  resolution  data,  PRA  interpolates 
this  data  down  to  a  resolution  of  200  -  400m  using  a  complicated  process  of  elliptical  fits  and 
PSD  filtering.  The  assumption  behind  the  PSD  filtering,  namely  that  the  cloud  spatial 
structure  is  scale  invariant  over  the  range  10  km  to  200m,  has  been  criticized  as  not 
validated.  PRA  has  also  been  seeking  higher  resolution  satellite  and  aircraft  data  that  do  not 
require  interpolation.  Sources  of  high  resolution,  low  coverage  data  should  be  used  where 
applicable.  However,  there  is  still  a  need  to  provide  high  resolution  databases  with  wide 
extent.  Thus,  the  current  method  of  interpolation  should  be  validated,  or  new  methods 
developed.  Fractal  or  wavelet  methods  might  be  useful  here.  In  addition,  cloud  interpolation 
techniques  might  lead  to  statistical  descriptions  of  cloud  tops  that  would  allow  synthetic 
generation  of  cloud  databases  to  supplement  those  derived  from  measurements. 

Several  assumptions  are  involved  in  transforming  apparent  brightness  maps  into  cloud 
altitudes.  The  accuracy  of  these  assumptions  should  be  tested  against  stereoscopic 
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measurements  of  cloud  tops,  if  such  data  exists. 


BRDFs 


CLDSIM  is  supplied  with  four  BRDFs  which  represent  scattering  off  of  spherical 
scatterers  in  two  altostratus  water  clouds,  a  cumulonimbus  water/ice  cloud,  and  a  cirrus  ice 
cloud.  A  separate  model  exists  for  specular  scattering  off  of  aligned  platelets  in  a  cirrus 
cloud.  The  precomputed  BRDFs  are  generated  using  a  Mie  scattering  code  and  an  adding 
and  doubling  method  treatment  to  determine  the  angular  distribution  of  radiation  scattered 
off  of  a  horizontally  homogeneous  slab  with  a  given  distribution  of  scatterer  sizes  and  a  given 
thickness.  The  BRDFs  represent  optically  thick  clouds,  which  tend  to  have  rather  smooth 
angular  distributions  of  scattered  radiation.  Although  CLDSIM  models  optically  thin  clouds 
by  apply  a  correction  that  reduces  the  overall  magnitude  of  the  scattered  radiance,  it  does 
not  adjust  the  angular  distribution  of  scattering.  It  thus  does  not  model  such  effects  as 
rainbows.  CLDSIM's  treatment  of  scattering  should  be  improved  to  produce  such  effects, 
either  by  interpolating  on  optical  depth  between  the  single  scattering  BRDF  and  the  optically 
thick  BRDF,  or  by  adopting  methods  developed  in  Chapter  3.  In  that  chapter  a  method  is 
developed  to  approximate  BRDFs  for  many  particle  distributions  very  quickly.  If  this  method 
were  employed,  it  would  increase  the  diversity  of  cloud  scattering  in  CLDSIM. 

Calculational  Steps 

CLDSIM  does  a  good  job  calculating  radiances  from  clouds,  especially  for  nadir  viewing 
geometries.  As  the  viewer  goes  to  lower  elevation  angles,  the  treatment  becomes  poorer, 
largely  due  to  deficiencies  in  cloud-on-cloud  interactions.  CLDSIM  handles  shadowing  on 
the  cloud  surface  locally.  A  pixel  is  in  shadow  or  not  depending  on  its  orientation  to  the  sun 
and  the  viewer.  The  shadowing  of  one  part  of  the  cloud  by  another  is  not  treated.  The 
illumination  of  part  of  the  cloud  by  radiation  scattered  off  of  another  part  is  handled  only 
diffusely,  as  an  multiplicative  correction  to  the  surface's  own  radiance.  The  shadowing 
treatment  in  CLDSIM  should  be  upgraded,  perhaps  by  using  low  resolution  renderings  of  the 
cloud  to  provide  shadows  and  illumination  for  the  higher  resolution  pixels  of  the  final  image. 
A  current  revision  of  the  code  will  improve  CLDSIM's  shadowing  techniques,  but  it  must  be 
finished  before  it  can  be  evaluated. 

CLDSIM  assumes  that  scattering  is  a  surface  effect,  rather  than  a  volume  effect.  This 
is  true  if  the  mean  free  path  for  scattering  is  small  compared  to  the  radius  of  curvature  of  the 
cloud.  Because  they  are  calculated  for  thick  slab  geometries,  CLDSIM's  BRDFs  may  not  do 
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as  well  calculating  radiances  from  "puffs"  in  a  cumulus  cloud  as  they  do  predicting  radiances 
from  a  stratus  deck.  Other  geometries  should  be  considered  in  calculating  BRDFs. 

Two  other  areas  need  improvement.  Currently,  CLDSIM  footprints  cloud  pixels  onto 
a  cylinder  that  curves  away  from  the  sensor,  rather  than  onto  a  portion  of  a  sphere.  There 
are  plans  to  upgrade  this  in  the  coming  years.  In  addition,  CLDSIM  uses  beam  transmission 
equations  that  may  underestimate  the  amount  of  ground  clutter  that  passes  through  clouds. 

CLDSIM  in  the  SSGM 


CLDSIM  is  increasingly  being  used  as  an  element  of  the  SSGM  rather  than  as  a  stand¬ 
alone  code.  The  SSGM  environment  poses  new  difficulties  that  do  not  exist  when  CLDSIM 
is  run  by  an  experienced  user  as  a  stand-alone  code.  A  complex  mixture  of  geometries, 
cloud  databases,  BRDFs  and  atmospheric  profiles  must  be  assembled  to  produce  any 
CLDSIM  run.  This  mixture  needs  to  be  assembled  in  a  physically  self-consistent  manner. 
The  implementation  of  CLDSIM  in  the  SSGM  tries  to  aid  the  user  by  making  certain  choices 
automatically.  For  instance,  the  correct  BRDFs  are  determined  in  the  SSGM  when  the  cloud 
databases  are  chosen.  While  this  is  a  good  start,  it  does  not  go  far  enough  it  keeping  the 
inexperienced  user  from  creating  an  unphysical  cloud  image  inadvertently.  Nor  is  there 
sufficient  information  supplied  with  a  cloud  image  to  inform  a  general  user  when  non- 
standard  cloud  parameters  are  used  by  an  experienced  user.  For  instance,  during  the  recent 
BASS  review,  CLDSIM  images  were  created  using  an  arctic  atmosphere  with  equatorial 
clouds  to  increase  contrast.  This  fact  became  less  well  known  as  the  images  were 
transmitted  from  person  to  person.  More  information  should  be  provided  to  the  user  to  aid 
in  constructing  consistent  cloud  images  and  more  error  checking  should  be  added  to  the 
code.  A  way  to  keep  warnings  about  non-standard  cloud  scenes  with  the  images  should  be 
developed. 

CLDSIM  has  an  architecture  that  sequentially  processes  whole  databases,  one  step 
at  a  time.  For  instance,  CLDSIM  calculates  pixel  scattering  geometries  for  millions  of  pixels 
in  a  databases,  even  if  only  a  few  of  them  are  in  the  FOV.  To  reduce  the  large  run  times  this 
produces,  a  "cookie  cutter"  utility  is  being  developed  for  the  SSGM  to  allow  the  user  to  create 
a  small  cloud  database  from  a  section  of  a  large  cloud  database.  This  is  part  of  a  revision 
of  CLDSIM  to  meet  faster  processing  goals  in  the  SSGM.  Adopting  a  pixel-oriented 
architecture  for  the  revision,  rather  than  a  database-oriented  one,  may  improve  CLDSlM's 
performance  even  more. 
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Visidvne's  MSLAB  Routine 


To  check  the  BRDF  treatment  in  CLDSIM,  Visidyne  adapted  Mie  and  slab  scattering 
routines  used  in  the  NORSE  nuclear  weapons  effect  code  to  produce  MSLAB.  The 
technical  details  of  this  code  are  given  in  Chapter  3.  MSLAB's  Mie  code  is  able  to  calculate 
accurate  scattering  patterns  for  both  small  and  large  scatterers.  The  slab  scattering 
treatment  in  MSLAB  calculates  the  single  scattering  BRDF  for  a  slab  of  arbitrary  thickness, 
and  adds  to  it  an  estimate  of  the  multiple  scattering  contribution.  Validation  runs  show  that 
MSLAB  does  a  good  job  calculating  scattering  patterns,  and  that  it  reproduces  the  variation 
of  BRDFs  with  optical  depth  and  particle  size.  MSLAB  includes  a  simple  model  of  gaseous 
absorption  inside  the  cloud  that  could  be  easily  upgraded  to  provide  better  results. 

MSLAB  is  a  fast  running  code.  It  could  be  used  in  a  general  cloud  modeling  code  to 
provide  BRDFs  for  a  wide  range  of  cloud  droplet  distributions  and  optical  thicknesses.  A 
slight  modification  of  the  code  would  allow  it  to  predict  scattering  off  of  surfaces  with  small 
radii  of  curvature. 

Line  Correlation  Transmission  Effects 

CLDSIM  calculates  transmissions  by  multiplying  the  transmission  through  a  cloud  with 
the  transmission  of  the  surrounding  atmosphere.  Line  oorrelations  between  gaseous 
absorbers  in  the  cloud  and  in  the  atmosphere  make  this  a  poor  approximation  in  important 
absorbing  regions.  A  calculation  is  presented  in  Chapter  4  showing  that  treating 
transmissions  as  uncorrelated  can  produce  an  underprediction  of  the  transmission  by  a  factor 
of  30  at  around  2.7  //m  for  a  5  km  altitude  cloud  and  by  a  factor  of  3  for  an  11  km  cloud. 
These  calculations  provide  an  explanation  for  a  difference  between  CLDSIM  predictions  and 
data. 

Conclusions 


A  table  of  conclusions  and  recommendations  is  provided  in  Chapter  5. 
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1.  INTRODUCTION 


Through  thermal  emission  and  scattered  solar  radiation,  clouds  present  a  significant 
clutter  source  to  infrared  surveillance  sensors  viewing  from  space.  To  simulate  these  effects 
for  the  defense  community,  Photon  Research  Associates  (PRA)  has  developed  over  a  series 
of  years  a  powerful  cloud  radiance  simulation  program  called  CLDSIM.  This  program  has 
been  used  to  generate  cloud  background  scenes  for  contractors  developing  new  sensors. 
It  is  also  a  major  component  of  the  Strategic  Scene  Generation  Model  (SSGM).  The  SSGM 
is  gaining  acceptance  as  a  standard  source  of  background  radiance  scenes  for  defense 
simulations.  CLDSIM  is  becoming  a  standard  source  of  cloud  backgrounds  along  with  it. 

Because  of  the  central  role  CLDSIM  is  assuming  in  providing  backgrounds  to  the  defense 
community,  it  has  been  the  subject  of  several  reviews  recently,  both  internally  at  PRA  and 
externally.  This  paper  reports  on  a  comprehensive  review  of  CLDSIM  that  Visidyne  was 
tasked  to  undertake.  This  review  has  benefited  from  the  cooperation  of  PRA,  but  it  has  been 
independent  of  that  company.  It  differs  from  previous  external  reviews  of  CLDSIM  by 
examining  not  only  CLDSIM's  results,  but  the  code  itself,  along  with  much  of  the  available 
documentation  on  CLDSIM. 

As  a  way  of  introduction,  Section  1 .1  briefly  describes  the  major  components  of  CLDSIM. 
Section  1 .2  describes  the  methodology  Visidyne  employed  to  review  CLDSIM. 

1 .1  Overview  of  CLDSIM 

Narrowly  defined,  CLDSIM  refers  to  a  PRA  developed  routine  that  models  infrared 
cloud  radiances.  It  does  so  by  combining  the  blackbody  thermal  emissions  at  cloud  altitudes 
with  solar  radiation  scattered  from  the  cloud's  top  surface.  CLDSIM  requires  many  sources 
of  data  to  perform  its  calculations.  It  uses  databases  of  cloud  altitudes  to  determine  the 
temperature  at  which  the  cloud  top  radiates,  as  well  as  descriptions  of  the  scattering 
properties  of  the  cloud  droplets.  It  also  takes  as  inputs  descriptions  of  the  incident  solar 
radiance,  along  with  skyshine  and  path  radiance.  Broadly  defined,  CLDSIM  refers  to  a  set 
of  codes  that  are  used  together  to  provide  the  information  required  to  produce  cloud  radiance 
scenes.  The  major  components  are 

(1)  Several  proprietary  PRA  routines  that  transform  measured  cloud  images  into 
databases  of  cloud  top  altitudes; 

(2)  PRA’s  proprietary  Multiple  Scattering  and  Radiation  Transport  (MSRAT)  code  that 
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computes  the  scattering  characteristics  of  clouds  as  expressed  through  Bidirectional 
Reflectance  Distribution  Functions  (BRDFs); 

(3)  The  APART  code  that  supplies  solar  irradiance,  thermal  and  solar  skyshine,  and 
thermal  and  solar  path  radiance  to  CLDSIM  for  specified  geometries  and  at  a  high  spectral 
resolution; 

(4)  The  CLDSIM  code  that  takes  inputs  from  these  other  codes  and  produces  cloud 
radiance  scenes. 

Although  CLDSIM  exists  as  a  stand-alone  code  at  PRA  and  a  few  other  locations,  most 
users  encounter  CLDSIM  as  part  of  the  SSGM.  Running  CLDSIM  in  the  SSGM  is  similar  to 
running  CLDSIM  alone,  except  that  (1)  the  SSGM  version  of  CLDSIM  generally  lags  the  PRA 
version  of  the  code  by  about  one  release,  and  (2)  some  of  CLDSIM's  options  have  been 
hardwired  to  predetermined  values  in  the  SSGM  implementation.  For  instance,  CLDSIM  has 
the  capability  to  add  an  offset  to  the  cloud  altitude  databases,  which  can  alter  the  predicted 
cloud  radiances  by  moving  the  clouds  to  a  different  temperature  level  and  by  changing  the 
amount  of  absorbing  atmosphere  above  the  cloud.  In  addition,  PRA  has  routinely  generated 
cloud  images  for  customers  with  stand-alone  CLDSIM  that  differ  from  those  produced 
through  the  SSGM  by  coming  from  a  cloud  altitude  database  not  distributed  with  the  SSGM, 
by  having  more  or  different  cloud  types  represented,  or  by  having  BRDFs  representative  of 
different  scattering  conditions.  Many  of  the  limitations  found  in  the  SSGM  version  of  CLDSIM 
are  actually  implemented  through  simple  entries  into  SSGM  text  files.  Thus,  a  determined 
user  could  reclaim  much  of  the  extra  functionality  of  the  corresponding  stand  alone  version 
of  CLDSIM  by  editing  a  few  files  (to  move  the  cloud  altitude  offset  for  instance),  or  by 
acquiring  the  extra  databases  and  BRDFs.  Since  the  general  user  will  encounter  CLDSIM 
through  the  SSGM  and  will  not  alter  its  implementation  there,  this  review  will  only  deal  with 
the  capabilities  found  in  the  standard  SSGM  version  of  CLDSIM.  While  the  formal  name  for 
this  version  is  CLOUD  /  HORIZON  in  SSGM  Release  5.1,  it  will  be  referred  to  as  CLDSIM 
in  this  review. 

Before  CLDSIM  is  delivered  to  the  SSGM,  cloud  top  altitude  databases  are  generated 
from  such  sources  as  NOAA  satellite  data.  This  is  done  assuming  that  the  measured 
apparent  brightnesses  can  be  converted  into  the  temperature  of  a  blackbody  radiator,  and 
that  an  atmospheric  profile  giving  temperature  as  a  function  of  altitude  can  be  constructed 
from  other  data.  Currently  seventeen  such  cloud  altitude  databases  are  available  in  the 
SSGM  to  simulate  clouds.  In  addition,  MSRAT  is  run  to  generate  BRDF  databases  which 
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give  the  reflected  radiance  resulting  from  a  unit  incident  irradiance  as  a  function  of  angle  and 
wavelength.  Since  scattering  patterns  depend  on  the  size  of  the  scatterer,  these  databases 
depend  on  the  distribution  of  cloud  droplet  radii.  In  the  SSGM,  four  BRDFs  are  available  to 
simulate  altostratus  clouds  at  4  km  cloud  base,  altostratus  clouds  at  6  km  cloud  base,  as  well 
as  cumulonimbus  and  cirrus  clouds. 

To  run  CLDSIM  in  the  SSGM,  the  user  specifies  which  cloud  altitude  database  to  use  and 
its  position  on  the  earth.  The  solar  position  is  computed  from  the  time  input,  and  the  user 
specifies  the  observer  location.  Given  these  inputs,  APART  is  run  to  provide  radiance  levels 
at  eleven  altitudes.  CLDSIM  then  loops  over  each  of  the  pixels  in  the  cloud  altitude  database 
to  determine  the  local  cloud  altitude  and  orientation.  The  altitude  and  cloud  emissivity  are 
used  to  determine  the  blackbody  radiance  from  the  pixel,  as  well  as  to  interpolate  the  APART 
outputs.  Scattering  angles  are  computed  with  respect  to  the  pixel's  surface  normal,  and  the 
BRDF  is  combined  with  the  interpolated  solar  irradiance  to  give  the  scattered  radiance.  To 
complete  the  calculation,  radiances  are  combined  to  form  the  total  radiance,  and  then 
footprinted  into  the  viewer's  perspective. 

It  should  be  noted  that  in  the  SSGM  the  user  does  not  run  CLDSIM  directly,  but  creates 
an  SSGM  input  file  outlining  the  scenario  of  interest,  and  starts  the  SSGM's  execution.  The 
SSGM  creates  the  correct  input  files  for  CLDSIM  and  APART,  obtains  the  radiance  output, 
and  combines  it  with  other  scenario  elements  to  produce  a  final  scene.  The  cloud  altitude 
databases  and  the  BRDFs  are  supplied  with  the  SSGM. 

1.2  Visidyne  Methodology 

Because  Visidyne  is  a  developer  of  one  of  the  components  of  the  SSGM,  Visidyne 
personnel  had  general  familiarity  with  CLDSIM  and  its  operation  before  this  review  began. 
To  complete  this  study  Visidyne  took  the  following  steps: 

(1)  Read  through  the  computer  code  for  CLDSIM  and  several  of  its  auxiliary  routines; 

(2)  Examined  available  manuals,  briefings  and  validation  reports; 

(3)  Interviewed  PRA  about  specific  features  of  CLDSIM;  and 

(4)  Performed  independent  cloud  radiance  calculations  as  a  check  on  CLDSIM. 

The  outline  of  this  report  is  as  follows.  In  Section  2,  a  description  of  each  of  the  major 
CLDSIM  components  is  presented,  followed  by  a  brief  critique.  Previous  validations  of 
CLDSIM  by  PRA  and  others  are  mentioned.  This  study  has  focused  on  the  version  of 
CLDSIM  that  was  available  in  the  last  release  of  the  SSGM,  Release  5.1 .  Since  that  release. 
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the  SSGM  has  undergone  extensive  revision  as  it  changes  from  its  Baseline  Phase  to  its 
Operational  Phase.  Several  corresponding  changes  to  CLDSIM  have  been  made  or  are 
being  planned.  To  show  how  CLDSIM  is  developing,  planned  PRA  changes  to  CLDSIM  are 
listed  for  each  component. 

Two  sets  of  independent  calculations  are  presented  in  this  report.  Because  solar 
scattering  is  a  significant  contributor  to  cloud  clutter,  an  evaluation  of  the  BRDFs  used  in 
CLDSIM  has  been  a  major  activity  of  this  review.  A  model  for  solar  scattering  was  adapted 
from  Visidyne's  NORSE  code,  and  BRDFs  were  calculated  for  comparison  to  CLDSIM's.  A 
full  description  of  the  model  and  the  results  is  provided  in  Section  3.  In  Section  4,  different 
methods  are  presented  for  handling  line  correlations  between  transmission  in  a  cloud  and 
in  the  surrounding  atmosphere.  These  calculations  give  an  explanation  for  a  discrepancy 
between  CLDSIM  predictions  and  data.  Recommendations  and  conclusions  make  up 
Section  5. 


2.  DESCRIPTION  OF  CLDSIM 

CLDSIM  models  the  thermal  emission  and  solar-scattered  radiance  of  clouds  as  observed 
by  satellite-borne  sensors.  CLDSIM  works  by  combining  the  databases  of  cloud  altitudes 
with  surface  reflection  data  and  radiation  transport  equations  to  produce  the  cloud  radiance 
scene.  -Each  of  these  components  will  be  described  below.  Each  description  is  followed  by 
a  critique  of  the  methods  used  in  CLDSIM.  Improvements  that  PRA  plans  to  make  to  the 
code  are  also  listed.  These  plans  come  from  (Mertz,  1993)  and  (Shanks  and  Mertz,  1993), 
as  well  as  from  discussions  with  PRA  personnel. 

2.1  Cloud  Altitude  Databases 

The  overall  features  that  one  sees  in  a  CLDSIM  image  come  from  the  information 
that  is  contained  in  one  of  CLDSIM's  cloud  altitude  databases.  (See  Table  1  for  a  list  of  the 
seventeen  databases  supplied  with  the  SSGM.)  The  process  of  creating  these  databases 
from  satellite  data  is  well  described  by  Mertz  (Mertz,  1991a),  who  delineates  the  steps  taken 
to  create  CLDSIM  databases  for  use  in  BSTS  studies.  The  steps  are 

(1)  Acquire  radiometric  images  of  clouds  and  atmospheric  temperature  profiles; 

(2)  Convert  cloud  brightnesses  to  altitudes  assuming  blackbody  radiation; 

(3)  Determine  cloud  types;  and 

(4)  Resize  the  database  to  the  desired  resolution. 
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Three  databases  were  constructed  for  the  BSTS  study  using  archived  data  from  the 
Advanced  Very  High  Resolution  Radiometer  (AVHRR)  aboard  NOAA-9.  This  instrument 
images  in  five  bands  with  an  average  resolution  of  1.1  km.  Coincident  temperature 
measurements  were  obtained  by  the  TOVS  sounding  product,  which  has  a  footprint  of 
around  17  km.  The  TOVS  data  gives  layer-mean  temperatures  at  a  given  location  as  a 
function  of  pressure  in  15  layers.  This  data  is  used  to  form  a  piece-wise  continuous 
temperature  profile  as  a  function  of  altitude,  using  hydrostatic  equilibrium  and  the  ideal  gas 
equation.  The  AVHRR  radiometric  data  is  then  converted  to  altitude  measurements 
assuming  that  the  cloud  top  is  a  blackbody  radiating  at  a  temperature  corresponding  to  the 
measured  apparent  brightness.  The  atmospheric  temperature  profile  is  applied  to  each 
pixel's  blackbody  temperature  to  produce  a  final  cloud  top  altitude.  Different  temperature 
profiles  are  used  for  different  pixel  groups  to  account  for  changes  in  temperature  due  to 
weather  fronts  or  geographic  boundaries. 

The  AVHRR  databases  contain  non-cloud  features  that  must  be  removed.  Visual 
inspection  of  the  multispectral  data  is  done  to  identify  underlying  land,  ice  and  water.  A  mask 
is  then  created  to  remove  them  from  further  consideration.  The  remaining  pixels  in  the 
images  are  classified  by  cloud  type.  In  the  SSGM,  the  types  are  altostratus  with  4  km 
altitude  base,  altostratus  with  6  km  base,  cumulonimbus  and  cirrus.  This  is  based  on 
brightness  thresholds,  which  translate  into  altitude  differences.  This  manual  typing  is 
checked  using  statistical  measures  of  the  altitudes  for  each  cloud.  Corrections  to  cloud 
altitudes  are  made  to  account  for  dimmer  apparent  brightnesses  at  thin  cloud  edges.  Also, 
when  one  cloud  covers  another,  the  boundaries  between  the  clouds  are  altered  to  make  the 
correct  join.  Two  databases  representing  the  cloud  result  from  this  work.  One  gives  cloud 
top  altitude  as  a  function  of  position,  and  the  other  contains  a  code  identifying  the  cloud  type 
of  each  pixel. 

Quite  often  users  want  cloud  databases  finer  than  the  1 .1  km  resolution  of  the  AVHRR. 
In  the  past,  PRA  has  employed  a  cloud  interpolation  scheme  to  produce  resolutions  of  200 
or  400  meters.  This  technique  involves  taking  each  row  of  the  altitude  database  and  finding 
all  minima  and  maxima.  Ellipses  are  fit  between  extrema  in  such  a  way  that  maxima  have 
zero  slope  while  minima  are  cusps.  These  ellipses  are  then  evaluated  at  the  desired 
resolution.  The  columns  of  the  altitude  database  are  similarly  fit  and  interpolated,  and  the 
two  sets  of  altitudes  are  averaged.  Because  this  process  creates  artifacts  in  the  database, 
the  PSD  of  the  database  is  formed  and  filtered  to  removed  spikes.  The  filtering  is  designed 
to  produce  a  PSD  with  the  same  k'“  roll-off  behavior  for  the  high  frequencies  corresponding 
to  the  new  interpolated  values  as  was  observed  in  the  highest  frequencies  of  the  original 
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data.  This  implements  PRA's  assumption  that  cloud  spatial  structure  is  scale  invariant  from 
10  km  to  200m.  The  inverse  transform  of  the  PSD  produces  the  final  altitude  database.  The 
resolution  of  the  cloud  type  database  is  increased  to  match  that  of  the  altitude  database. 


TABLE  1.  Cloud  databases  available  in  the  SSGM 


Database 

Cloud  Types  (from 
Assigned  BRDFs) 

Number  of 

Pixels 

(Millons) 

Pixel  Size 
(m) 

EWx  NS 
Extent  (km) 

alto/test 

cumulo 

0.016 

400 

51  x51 

CIRRUS/EQUATORIAL 

cirrus 

2.2 

120 

180x177 

CUMNIMBATROP 

cumulo 

1.05 

400 

410x410 

BAJA 

alto6,  cumulo,  cirrus 

1.05 

120 

123  X  123 

CIRRUS/MONSOON 

cirrus 

2.2 

120 

180x177 

ALTOSTRAT/MIDLAT 

alto6 

1.05 

400 

410x410 

CIRROSTRAT/MIDLAT 

cirrus 

1.05 

400 

410x410 

OCEAN/MIDLAT 

alto6,  cumulo,  cirrus 

31.90 

200 

573  X  2228 

STRATOCUM/MIDLAT 

alto6 

2.3 

120 

188  X  176 

STRATUS_STREETS 

alto6 

1.05 

120 

123x123 

SILOFIELDS 

alto6,  cumulo,  cirrus 

3.42 

200 

205  X  668 

VASSA 

alto6,  cumulo,  cirrus 

50 

200 

800  X  2500 

KIJEV 

alto6,  cumulo,  cirrus 

46.8 

200 

800  X  2340 

KIJEV_NORTH 

alto6,  cumulo,  cirrus 

24 

200 

800  X  1200 

BALTIC 

0.0655 

1000 

256  X  256 

ALTOCUM/POLAR 

alto6 

5.12 

30 

31  X  150 

CUMNIMB/POLAR 

cumulo 

5.12 

30 

31  X  150 

Critique  of  the  Databases 


CLDSIM's  databases  can  be  evaluated  in  terms  of  their  spatial  coverage  and  resolution, 
and  in  terms  of  how  well  they  span  the  collection  of  clouds  that  one  might  encounter.  Users 
generally  request  databases  with  fine  spatial  resolution  and  wide  area  coverage  to  use  in 
simulations.  PRA  has  tried  to  accommodate  these  requests,  as  the  size  of  some  of 
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CLDSIM's  databases  attests.  However,  the  number  of  sources  that  collect  and  archive  such 
data  is  limited.  NOAA  data  at  1.1  km  resolution  is  available,  and  PRA  has  routinely 
interpolated  such  data  down  to  finer  resolutions.  The  interpolation  process  was  questioned 
during  the  BASS  study  (Albright,  1992).  The  point  made  was  that  validation  needed  to  be 
done  to  determine  the  range  of  sizes  over  which  scale  invariance  holds.  At  some  scale, 
edge  structure  might  be  encountered  that  would  produce  higher  clutter  signals  than  predicted 
by  the  PSD-continuation  method.  Alternatively,  highly  correlated  features  might  appear  that 
would  produce  less  clutter  at  small  scales  than  scale  invariance  predicts. 

To  avoid  doing  this  interpolation,  PRA  has  acquired  30m  resolution  data  from  LandSat, 
although  this  is  not  a  perfect  solution  either.  Besides  the  cost  involved  in  acquiring  such 
data,  there  is  the  intrinsic  problem  that  LandSat  sensors  are  designed  to  image  land  features. 
In  LandSat's  analogue-to-digital  conversion  of  the  measured  radiance,  few  bits  are  allocated 
to  the  radiance  range  associated  with  clouds,  thus  reducing  the  accuracy  of  the  cloud  data. 
PRA  is  also  investigating  acquiring  aircraft  data  from  NASA's  ER-2  to  provide  high  resolution 
data. 

Although  high  resolution  data  should  be  used  where  possible,  cost  and  availability 
considerations  still  leave  a  place  for  generating  realistic,  fine  resolution  databases  from 
coarse  data.  Therefore,  it  is  recommended  that  the  PRA  interpolation  scheme  be  validated 
using  high  resolution  databases  that  have  been  resampled  to  lower  resolution  and  then 
interpolated  to  finer  resolution  again.  PRA  has  pointed  out  that  using  scale  invariance  is 
equivalent  to  assuming  that  cloud  structure  is  fractal  in  nature  over  a  certain  range.  The 
fractal  dimension  of  the  structure  in  a  cloud  database  can  be  related  to  the  slope  of  the  PSD 
used  to  generate  it.  A  comparison  of  CLDSIM  database  fractal  dimensions  to  the  range  of 
dimensions  reported  in  the  cloud  literature  would  be  useful.  In  general,  Fourier  techniques 
have  difficulty  generating  realistic  cloud  structure  because  the  information  needed  to  produce 
the  sharp  edges  seen  in  clouds  is  represented  in  the  Fourier  domain  by  complex 
relationships  between  the  phases  of  the  Fourier  components.  It  is  believed  that  PRA's 
interpolation  method  avoids  this  problem  by  using  phases  generated  from  the  elliptical  fits 
and  by  only  altering  the  magnitudes  of  the  components  during  the  filtering  process. 
Nevertheless,  other  methods  of  interpolation  that  do  not  require  Fourier  transforms,  such  as 
wavelets  or  traditional  fractal  techniques,  might  be  investigated.  If  scaling  laws  for  features 
of  various  sizes  can  be  developed  and  validated,  these  techniques  might  be  used  to 
generate  synthetic  cloud  altitude  maps.  This  would  provide  a  greater  variety  of  cloud 
realizations  to  CLDSIM. 
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The  question  of  the  span  of  the  conditions  represented  by  the  databases  is  tied  to  how 
they  came  into  being.  Historically,  the  databases  have  been  produced  at  the  request  of  one 
or  more  project  offices  wishing  to  simulate  certain  scenarios.  Thus,  there  is  a  high 
concentration  of  cloud  databases  over  the  former  Soviet  Union.  In  selecting  data  sets  to 
process,  PRA  looks  at  the  archived  data  for  the  region  of  interest  and  chooses  cloud 
conditions  that  are  representative  of  stressing  conditions.  Measured  against  the  clouds  in 
the  given  region,  the  databases  in  CLDSIM  are  typical.  The  databases  developed  for 
specific  projects  become  available  to  the  general  defense  community  through  the  SSGM, 
which  raises  the  more  general  question  of  whether  the  set  of  CLDSIM  databases  span  the 
range  of  clouds  one  could  encounter  for  all  scenarios.  This  is  a  difficult  question  to  answer, 
largely  because  one  needs  to  develop  a  log  of  cloud  returns  observed  by  sensors  over  a  long 
period  of  time.  The  BASS  study  concluded  that  DSP  data  should  be  obtained  to  develop 
such  a  log.  Until  this  can  be  done,  PRA  has  worked  to  improve  the  coverage  of  databases 
by  picking  new  geographic  locations  and  cloud  types  to  include.  In  the  last  year,  the  number 
of  SSGM  databases  has  grown  from  10  to  17,  with  a  mix  of  clouds  from  all  latitudes. 

A  few  general  comments  can  also  be  made  about  the  limitations  of  PRA's  method  of 
acquiring  altitude  databases.  To  obtain  good  IR  images  for  cloud  altitude  maps,  PRA  selects 
NOAA  data  with  high  observer  and  solar  elevation  angles  to  minimize  shadowing.  (NOAA-9, 
used  for  the  BSTS  measurements,  has  local  equatorial  crossing  times  of  2:30  and  14:30.) 
This  high  elevation  geometry  emphasizes  structural  details  of  the  top  surface  of  the  cloud 
over  that  of  the  cloud  sides.  This  is  not  much  of  a  problem  if  CLDSIM  is  used  to  simulate 
images  of  high  altitude  surveillance  sensors  in  orbits  similar  to  NOAA  satellites,  or  if  it  is 
modeling  cloud  types  with  little  vertical  development.  However,  CLDSIM  probably  would 
have  trouble  modeling  a  thunderhead  viewed  from  low  elevation  angles  just  using  information 
obtained  from  high  elevation  data.  In  addition,  if  an  optically  thick  cloud  lies  above  another 
cloud,  it  is  difficult  to  determine  the  surface  features  of  the  lower  cloud  using  high  elevation 
geometries.  It  is  recommended  that,  if  such  data  can  be  located,  using  stereoscopic 
measurements  of  cloud  surfaces  be  considered  to  supplement  current  cloud  altitude 
processing  techniques.  The  proposed  RAMOS  experiment  would  provide  such  data. 

When  comparing  CLDSIM  to  NOAA  SWIR  data,  Mertz  (1991b)  pointed  out  that,  besides 
surface  variation  effects,  clutter  in  SWIR  cloud  radiances  comes  from  variations  in  liquid 
water  content  (LWC)  across  the  cloud.  He  proposed  adding  measures  of  the  LWC  obtained 
from  water  absorption  bands  as  a  way  to  increase  cloud  structure,  especially  for  stratus 
clouds  which  may  have  rather  smooth  tops.  While  this  might  be  a  worthwhile  addition  to  the 
model,  CLDSIM  would  have  to  change  its  method  of  handling  BRDFs  to  allow  them  to  vary 
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with  water  content.  The  methods  developed  in  Section  3  serve  as  one  model  for  how  this 
can  be  done. 

Planned  PRA  Improvements  to  the  Cloud  Databases 

PRA  will  continue  to  add  more  moderate  resolution  (30-120  m)  databases  for  future 
releases  of  the  SSGM.  One  new  database  is  scheduled  for  the  SSGM  Release  6.0  in  April 
of  1994,  with  perhaps  4-8  more  available  in  late  in  1994  or  1995.  PRA  is  investigating  using 
ER-2  aircraft  measurements  to  improve  spatial  resolution. 

PRA  is  developing  global  scale  databases  that  will  be  run  with  simplifications  of  the 
CLDSIM  model.  For  instance,  diffuse  scattering  will  be  used,  rather  than  relying  on  BRDFs. 
These  databases  are  useful  for  scenarios  with  long  flyouts  or  for  geosynchronous 
observations  of  the  earth.  For  Release  6.0,  a  database  with  25-50  km  resolution  will  be 
provided,  while  four  more  databases  at  4  km  resolution  will  be  developed  for  future  releases. 

2.2  BRDFs 

Besides  the  cloud  altitude  and  type  databases,  CLDSIM  requires  precomputed  tables 
of  Bidirectional  Reflectance  Distribution  Functions  (BRDFs).  A  BRDF  Pbd  is  defined  in  the 
following  way:  Let  Hj(0|)  be  the  irradiance  at  one  wavelength  incident  on  a  surface,  and  let 
Lr(6r,ct))  represent  the  reflected  radiance.  Here  the  0's  are  zenith  angles  measured  with 
respect  to  the  surface  normal  and  ({)  is  the  azimuth  angle  between  the  incoming  and  outgoing 
radiation.  Then  Lr(0r,cj))  is  given  by 

LjQ^,(t>)  -  [H.(e.)cos(e.)  ]  cos(e^)  d) 


If  Hr  is  the  irradiance  reflected  into  2n,  the  directional  reflectance,  Pp  is  defined  by 


=  [H.{e.)cos{d.)] 


(2) 


This  gives 
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(3) 


e^,  $)  cos  (0^^) 

2n 

BRDFs  are  calculated  for  CLDSIM  using  the  Multiple  Scattering  and  Radiation  Transport 
code,  MSRAT.  This  routine  computes  the  BRDF  of  a  horizontally  homogeneous  cloud  of  a 
specified  thickness,  using  an  adding  and  doubling  method.  This  method  divides  a  region 
into  small  layers,  each  thin  enough  so  that  only  single  scattering  is  important.  Upward  and 
downward  going  fluxes  for  these  layers  are  computed,  and  successively  larger  layers  are 
constructed  by  combining  sublayers,  until  the  fluxes  for  the  whole  cloud  are  determined. 
The  single  scattering  properties  of  the  sublayers  are  computed  using  Mie  theory,  which 
assumes  scattering  by  a  distribution  of  spherical  droplets  of  ice  or  water.  Absorption  of 
radiation  inside  the  cloud  by  gaseous  species  is  included  by  fitting  the  transmission  as  a 
function  of  centimeters  of  percipitable  water  vapor, 

Table  2  -  Precomputed  MSRAT  BRDFs 


Database 

Cloud  Type 

alto4.db 

water 

altoS.db 

water 

cumulo.db 

ice  above  water 

cirrus.db 

ice 

BRDF  Variable 

Range 

Incident  Zenith  Angle 

4  angles  :  0,  30  ,60  ,80° 

Reflected  Zenith  Angle 

5  angles  :  20,  45,  60,  72.5,  84.3° 

Azimuth 

9  angles  :  0,  30,  50,  70  90,  110,  130,  150,  180° 

Wavelength 

50  values,  1  - 12.5  mm,  variable  resolution 

y,  to  a  series  of  exponentials  (Stephens,  1978). 


N  N 

T(y)  'EpikJ^l 

n=l  n-1 


(4) 


This  allows  one  to  handle  gaseous  absorption  in  the  adding  and  doubling  method  by 
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adjusting  the  optical  depths  and  single  scattering  albedo  of  each  of  the  sublayers  to  include 
the  optical  depth  due  to  one  of  the  k,.  The  BRDF  is  calculated  for  each  n,  and  then  averaged 
to  give 

=E  P^(e.,e^,4))  (5) 

n=l 

The  four  precomputed  BRDF  databases  that  are  supplied  with  the  SSGM  are  listed  in  Table 
2.  The  BRDFs  are  computed  for  specific  wavelengths,  incident  angles  and  reflected  angles, 
which  are  also  given  in  the  table.  Along  with  the  BRDF  values,  the  databases  contain 
values  of  the  cloud  extinction,  directional  reflectance  and  directional  emissivity  as  a  function 
of  wavelength. 

Mie  theory  assumes  spherical  scatterers.  This  is  a  good  model  to  use  for  water  droplets, 
but  does  not  adequately  represent  scattering  from  ice  in  cirrus  clouds.  There,  ice  platelets 
align  horizontally  due  to  hydrodynamic  forces  and  can  produce  large  specular  returns.  To 
handle  this  situation,  CLDSIM  uses  a  specular  scattering  model  (Shanks,  1 991 ).  The  model 
assumes  a  gamma  distribution  of  ice  particle  volumes  and  uses  empirical  relations  to 
compute  their  area.  Geometric  optics  calculations  are  done  to  determine  the  expected 
reflected  flux  for  a  given  set  of  incident  and  reflected  angles.  Due  to  statistical  variations 
from  perfect  allignment,  this  flux  is  spread  out  over  a  lobe  of  a  few  degrees  FWHM.  The  size 
and  shape  of  this  lobe  comes  from  a  model  that  takes  as  input  the  surface  roughness  and 
the  correlation  length  of  the  particle  misalignment.  The  SPCTBL  routine  is  installed  in  the 
SSGM  to  allow  computations  of  BRDFs  with  this  model.  Due  to  the  great  computation  time 
involved,  two  precomputed  databases  are  also  supplied,  one  for  a  SWIR  band  and  another 
for  a  band  in  the  MWIR.  These  databases  give  a  band-specific  BRDF  as  a  function  of 
scattering  angles  and  optical  depth.  In  the  SSGM  implementation  of  CLDSIM,  the  user  may 
choose  whether  or  not  to  use  the  specular  model.  If  chosen,  it  is  applied  to  those  cloud 
databases  which  contain  cirrus  clouds.  The  top  10%  of  the  cirrus  cloud  is  assumed  to 
contain  oriented  ice  crystals,  while  the  bottom  90%  contains  spherical  ice  scatterers. 

Critique  of  the  MSRAT  BRDFs 

PRA  has  validated  these  calculations  by  comparing  the  BRDFs  generated  to  a  Monte 
Carlo  BRDF  calculation,  to  other  adding  and  doubling  calculations,  and  to  experimental  data. 
(See,  for  instance,  Blasband  and  Jafolla,  1 990.)  A  major  focus  of  the  present  CLDSIM  review 
has  been  on  investigating  CLDSIM's  BRDFs.  In  Section  3,  another  approach  to  BRDF 
calculations  is  presented  and  compared  to  the  CLDSIM  BRDFs.  In  Section  4,  differences 
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between  CLDSIM  results  and  measured  radiances  are  attributed  to  the  absence  of  correlated 
line  transmission  between  the  cloud  scattering  volume  and  the  surrounding  atmosphere. 

Detailed  discussion  of  the  BRDFs  will  be  taken  up  in  those  later  sections.  For  now,  a  few 
general  comments  will  suffice.  First,  although  the  MSRAT  code  can  produce  BRDFs  for 
clouds  of  varying  optical  thickness,  the  BRDFs  delivered  in  the  SSGM  correspond  to  optically 
thick  clouds.  As  will  be  shown  later,  BRDFs  of  such  clouds  tend  to  have  rather  smooth 
variations  as  a  function  of  angle,  while  BRDFs  for  thinner  clouds  contain  peaks 
corresponding  to  glory  scattering  (180°  backscatter)  and  rainbows  (at  abouf  140 
backscatter).  These  are  remnants  of  the  phase  function  used  for  single  scattering  and  tend 
to  produce  more  contrast  in  cloud  scenes. 

To  account  for  the  drop  in  reflected  radiance  in  thin  clouds  due  to  incomplete  scattering, 
CLDSIM  modulates  its  BRDFs  by  the  cloud  opacity,  rather  than  calculating  a  new  BRDF  for 
each  pixel.  If  t  is  the  cloud  optical  thickness,  then  the  PRA  technique  uses 

p^^(T)  =  (1-e-^)  (6) 

While  this  technique  accounts  for  a  drop  in  reflected  flux,  it  does  not  reproduce  peaks  in  the 
BRDF  seen  in  thin  clouds  when  CLDSIM's  starting  BRDF  corresponds  to  an  optically  thick 
cloud.  A  simple  fix  to  this  problem  would  be  to  interpolate  smoothly  between  the  single 
scattering  solution  and  a  large  thickness  solution  as  a  function  of  optical  depth.  The  single 
scattering  solution  for  a  given  optical  depth,  S(t),  is  a  simple  analytic  expression  that  is 
developed  in  Section  3.  Using  this  method,  the  correction  for  finite  optical  depth  would  be 

(l-e-^)+S(T)  (7) 

Section  3  also  presents  a  method  of  quickly  computing  BRDFs  for  various  optical  depths 
which  goes  beyond  the  single  scattering  technique.  If  either  method  of  improving  the  thin 
cloud  BRDFs  is  employed,  the  angular  resolution  of  BRDFs  will  need  to  be  finer  than 
presently  available  in  CLDSIM. 

CLDSIM's  BRDFs  can  also  be  evaluated  in  terms  of  variety.  The  SSGM  is  supplied  with 
four  BRDFs  which  represent  a  cirrus  cloud,  a  cumulonimbus  cloud,  an  altostratus  cloud 
between  4  and  4.5  km  altitude,  and  an  altostratus  cloud  between  6  and  6.5  km.  When  the 
actual  values  of  the  BRDFs  are  compared,  one  finds  that  the  two  water  cloud  BRDFs  are 
very  similar,  as  are  the  cirrus. db  and  cumulo.db.  As  a  sample  of  the  BRDFs,  the  0°  solar 
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angle  directional  reflectances,  Pd(0)  are  plotted  in  Figs.  1  and  2.  Note  that  equation  3  implies 
that  the  Qp  are  averages  of  the  BRDFs  over  reflected  angles.  Examination  of  these  figures 
shows  that  the  cirrus. db  and  cumulo.db  values  are  essentially  identical  in  these  important 
sensor  bands,  although  they  do  diverge  from  each  other  below  2.5  pm.  The  two  alto 
databases  show  more  variation,  especially  in  the  4.35  to  4.5  pm  region.  This  is  due  to  an 
increase  in  gaseous  absorption  in  the  lower  cloud  relative  to  the  higher  cloud.  However,  if 
one  looks  at  Table  1 ,  one  sees  that  the  alto4.db  is  only  used  in  the  BALTIC  database.  Thus, 
in  these  two  regions,  one  is  largely  left  with  two  available  BRDFs,  one  for  a  water  cloud  and 
another  for  an  ice  cloud. 

The  similarity  of  the  BRDFs  reflects  the  fact  that  they  were  created  for  optically  thick 
clouds,  where  the  effects  of  particle  microphysics  is  minimal.  The  number  of  available 
BRDFs  should  increase  to  more  accurately  model  thinner  clouds.  However,  a  difficulty  in 
having  more  cloud  BRDFs  is  that,  if  one  is  going  to  differentiate  cloud  types  more  closely,  the 
process  of  typing  the  cloud  altitude  databases  will  become  much  more  difficult.  One  possible 
solution  is  to  allow  the  user  to  apply  several  different  BRDFs  to,  say,  a  water  cloud  currently 
typed  as  alto. 

Planned  PRA  Improvements  to  the  BRDFs 

The  present  BRDFs  in  CLDSIM  are  being  recalculated  for  the  April  1 994  Release  6.0  of 
the  SSGM  to  extend  the  spectral  range  from  1-12.5  /^m  to  .2  - 15  i^m.  The  resolution  from 
2.6  -3.0  Aim  will  go  from  .04  mm  to  .01  mm.  These  BRDFs  will  have  adjustments  to  their 
microphysical  parameters.  In  addition,  the  angular  resolution  of  the  BRDFs  will  change  from 
4  solar  zenith  angles  to  12,  from  5  observer  angles  to  15,  and  from  9  azimuth  angles  to  27. 
For  Release  7.0  in  late  1994,  two  new  BRDFs  are  also  planned.  These  may  be  a  thin  cirrus 
cloud  and  a  stratocumulus  cloud. 

2.3  Steps  in  the  CLDSIM  Calculation 

When  CLDSIM  is  run  in  the  SSGM,  a  series  of  separate  programs  are  executed  in 
succession.  The  major  ones  are  APART,  which  produces  input  radiances  and  fluxes  on  a 
fine  spectral  scale;  ATCALC,  which  converts  these  to  inband  quantities;  and  CLDSIM,  which 
produces  radiances.  CLDSIM  itself  is  divided  into  CLDTPO,  CLDGEO,  CLDRAD  and 
FOOTPR,  which  determine  the  cloud  top  normals,  calculate  scattering  angles,  put  together 
the  pieces  that  form  the  radiance  for  each  cloud  pixel,  and  footprint  the  pixel  radiances  for 
the  viewer's  perspective.  These  functions  will  be  described  below. 
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Directional  Reflectance 


Figure  1-  Directional  reflectance  in  the  SWIR 


Figure  2.  Directional  reflectance  in  the  MWIR 
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Table  3  is  useful  in  describing  the  variables  encountered. 


A  user  wishing  to  run  CLDSIM  in  the  SSGM  begins  by  setting  up  a  Scenario  Definition 
File  (SDF).  This  file  gives  the  input  choices  to  the  user.  They  include 

(1 )  the  date  and  time  of  day  (to  fix  the  solar  position); 

(2)  the  observer  position; 

(3)  the  wavelength  limits  of  the  sensor,  or  a  file  giving  its  spectral  response; 

(4)  the  IFOV  and  number  of  pixels  in  the  output  scene; 

(5)  the  cloud  altitude  database  desired; 

(6)  the  latitude  and  longitude  of  the  altitude  database  (to  locate  it  on  the  earth); 

(7)  the  atmospheric  profile  (temperature  and  pressure  as  a  function  of  altitude)  from 
a  list  of  profiles; 

(8)  the  type  of  terrain  background  to  put  below  the  clouds. 

Other  switches  are  also  available  to  do  such  things  as  turn  on  or  off  the  specular  BRDF 
for  cirrus  clouds,  or  to  produce  diagnostic  plots  that  identify  the  cloud  type  below  each  pixel. 

The  SSGM  takes  this  information  and  prepares  input  decks  for  the  various  codes.  It  first 
calls  APART,  which  supplies  temperature,  transmission,  solar  irradiance,  thermal  and  solar 
skyshine,  and  thermal  and  solar  path  radiance.  These  quantities  are  defined  for  eleven 
altitudes,  from  0  to  10  km,  and  at  a  high  spectral  resolution.  The  inputs  to  this  routine  are 
the  model  atmosphere  (from  a  list  of  23  choices)  and  the  solar  and  observer  positions.  For 
purposes  of  interpolation,  APART  is  run  twice,  each  time  using  one  of  two  solar  zenith  angles 
that  bound  the  range  of  solar  positions  that  exist  at  different  parts  of  the  cloud  database. 
This  allows  the  solar  angle  to  vary  across  the  cloud.  In  addition,  the  observer  zenith  angles 
at  the  four  corners  of  the  cloud  database  are  used  to  bound  the  observer  angle,  with 
interpolation  for  this  variable  occuring  inside  the  cloud.  It  should  be  noted  that  when  a  time 
series  of  cloud  images  is  requested  (a  "movie"  to  use  the  SSGM  term),  the  solar  and 
observer  positions  are  fixed  to  be  that  of  the  center  time  for  the  time  series.  Thus,  the  sun 
and  observer  do  not  move  over  the  time  interval.  Rather,  the  final  output  is  simply  foot 
printed  into  the  correct  viewer  position  for  each  time. 

APART  is  based  on  LOWTRAN  and  provides  radiant  quantities  at  5  cm'^  resolution. 
Inband  quantities  are  required  for  the  final  output.  The  SSGM  calls  ATCALC  to  integrate 
APART  output  over  a  spectral  band,  using  a  user-specified  spectral  response  function  if 
desired.  ATCALC  also  takes  the  temperature  information  from  the  APART  output  to  create 
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Table  3.  Quantities  used  in  CLDSIM 


Variable 

Description 

®soi  J  ®obs  >  4^ 

Solar  Zenith  Angle,  Observer  Zenith  Angle,  Azimuth, 
measured  relative  to  the  local  vertical 

0=01 . 0  'oM  . 

Solar  Zenith  Angle,  Observer  Zenith  Angle,  Azimuth, 
measured  relative  to  the  cloud  surface  normal 

z 

Altitude 

A 

Wavelength  (or  band  of  wavelengths) 

T(z) 

Temperature  at  altitude  z 

t(A,z) 

Transmission  from  altitude  z  to  the  observer 

X(A) 

Cloud  extinction  (per  km  of  cloud) 

QP  (z-z,ot,  6) _ 

Cloud  opacity  (with  Zh„,  the  altitude  of  the  cloud  bottom  ) 

Pp  (9soi ,  A) _ 

Directional  reflectance  of  the  cloud 

e  (e.n, ,  A) 

Directional  emissivity  of  the  cloud 

Pbd(Q'soI  '  Q  'ohs  ■  4^'. 

Cloud  Bidirectional  Reflectance  Distribution  Function  (BRDF) 

. ggrnd  (  ^  ) _ _ 

Emissivity  of  the  ground 

Solar  irradiance 

Blackbody  radiance  determined  by  the  local  temperature 

Thermal  path  radiance 

^DS  (Q  SQi  >  Q  Qbs  L  _ 

Solar  path  radiance 

(Q  sol  »  Q  Qbs  > 

Thermal  skyshine  radiance 

^ss  (9  sol  J  ®  Ohs  j 

Solar  skyshine  radiance 
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tables  of  inband  blackbody  radiance  at  the  1 1  altitudes.  It  merges  the  radiance  information 
from  APART  with  the  BRDFs  to  produce  the  input  files  necessary  to  run  CLDSIM  itself. 

When  CLDSIM  is  invoked,  the  code  first  runs  its  CLDTPO  routine.  CLDTPO  determines 
the  normal  to  the  cloud  surface  at  each  pixel  by  fitting  a  plane  through  the  four  surrounding 
points.  Special  attention  is  given  to  cloud  edges  which  don't  have  all  four  surrounding  pixels 
covered  by  clouds  of  the  same  type.  When  CLDTPO  finishes,  it  writes  out  a  file  four  times 
larger  than  the  original  cloud  altitude  database.  It  contains  the  cloud  altitude  and  the  three 
components  of  the  surface  normal  for  each  pixel. 

CLDSIM  next  calls  CLDGEO,  which  uses  the  observer  and  solar  position  (at  the  center 
time  of  a  time  series)  to  calculate  the  solar  zenith  angle,  observer  zenith  angle  and  the 
azimuth  angle  between  the  sun  and  the  observer  for  each  pixel.  Two  sets  of  angles  are 
computed.  The  first,  Bsq,,  and  cj),  are  measured  relative  to  the  local  vertical,  with  the 
second,  B  ’3^1,  B'^^s  .  and  cf)',  are  measured  relative  to  the  surface  normal.  The  latter  set  is 
used  for  solar  scattering.  CLDGEO  ends  after  creating  a  file  that  contains  the  cosines  of 
these  six  angles  listed  for  each  pixel. 

CLDRAD  is  next  called  by  CLDSIM  to  calculate  the  radiance  for  each  pixel.  Inputs  are 
the  ATCALC  output  file,  the  cloud  altitude  file,  and  the  file  containing  the  six  cosines  for  each 
pixel.  The  routine  loops  over  pixels  and  performs  the  necessary  interpolations  on  the  radiant 
quantities.  Most  quantities  must  be  interpolated  over  the  solar  and  observer  zenith  angles 
(measured  relative  to  the  local  vertical),  as  well  as  the  altitude.  The  BRDF  must  be 
interpolated  over  the  two  zenith  angles  and  azimuth  angle  that  are  measured  with  respect 
to  the  surface  normal.  All  interpolations  are  done  on  the  logarithm  of  the  radiance.  The 
radiant  quantities  are  combined  in  one  of  several  ways,  depending  on  angular  conditions. 
If  the  surface  normal  is  not  directed  toward  the  observer  (  B'^^s  >  90°),  the  pixel  is  assumed 
to  be  in  a  shadow,  and  no  radiance  is  returned.  In  addition,  if  the  solar  zenith  Bgo,  is  greater 
than  90°,  "night  time"  calculations  are  performed  for  the  pixel.  This  involves  turning  off  solar 
scattering  and,  if  the  sun  is  below  a  user  selected  angle,  the  solar  path  radiance.  For  night, 
the  equation  used  by  CLDRAD  is 


=  [e*x 

:  cloud  blackbody 

:  solar  +  thermal  skyshine 

:  thermal  path  radiance 

:  background  radiance 
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while  for  "daytime"  conditions,  CLDRAD  uses 


L  )Pg^*Op 

-  (H,,*cos  (6^^,)  )p^^Op*  (p^/24) 
+  [e^x  *L^^*Op]  *  (l+p^/24) 
Mp^-(L^,-L^,)]Ml+py24) 

+  *0p 


:  reflected  solar  radiance 
:  diffuse  solar  radiance 
:  cloud  blackbody 
:  solar  +  thermal  skyshine 
:  solar  thermal  path  radiance 
:  background  radiance 


(9) 


A  few  quantities  in  these  expressions  deserve  further  explanation.  The  opacity,  Op,  is 
obtained  using  the  cloud  extinction  contained  in  the  BRDF  datafile,  multiplied  by  the  vertical 
distance  between  the  cloud  top  and  cloud  bottom.  It  is  used  to  adjust  the  cloud  radiance  for 

Op-l-e'^  ■  (20) 


small  optical  depth.  The  terms  proportional  to  PJ2A  approximate  the  diffuse  radiance  from 
the  cloud's  environment.  The  background  radiance,  L^kg,  represents  the  radiance  of  the 
underlying  terrain.  It  can  come  from  a  file  containing  radiances  calculated  using  PRA's 
GENESSIS  model,  or  it  can  be  determined  from  a  statistical  description  of  the  reflectance  of 
the  ground.  From  a  user-supplied  pair  of  mean  reflectance  and  variance  values,  CLDRAD 
can  calculate  a  random  emissivity  for  each  pixel,  and  determine  the  radiance  for  "night  time" 
conditions  using  the  equation 

^bkg  ^^bb*'^’^^grnd  '  Sround  blackhody  radiation 

( 11 ) 

:  thermal  path  radiance 


For  daylight  conditions,  the  equation  is 

^bkg  "^bb*'^'^^gznd  '  S^ound  blackbody  radiation 

■■  reflected  sunlight  (22) 

+  ■  solar thermal  path  radiance 

All  of  these  quantities  refer  to  ground  conditions  with  2  =  0. 

The  final  call  to  a  major  CLDSIM  routine  is  to  FOOTER,  which  transforms  the  cloud  scene 
from  a  pixelization  based  on  the  altitude  database  to  one  based  on  the  sensor  IFOV.  This 
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routine  assumes  that  the  cloud  database  is  a  portion  of  a  cylinder  curving  away  from  the 
viewer.  This  allows  for  foreshortening  effects,  but  does  not  accurately  represent  the 
curvature  of  the  earth  in  the  azimuth  direction.  Following  the  FOOTPR  call,  the  output 
radiance  scene  is  composited  with  other  scene  elements  in  the  SSGM. 

In  discussing  the  steps  used  to  produce  a  CLDSIM  image,  several  details  have  been 
omitted.  For  instance,  a  cloud  transmission  file  can  be  created  from  the  computed  opacity 
values.  This  file  can  be  used  to  obscure  objects  below  the  cloud.  Further,  CLDSIM  can  be 
run  with  the  HORIZON  code  to  produce  a  scene  with  clouds  merging  with  the  earthlimb. 
Special  techniques  are  used  to  match  radiances  at  the  horizon,  but  they  will  not  be  treated 
here. 

PRA's  Validation  of  CLDSIM 


PRA  has  performed  several  studies  to  validate  parts  of  CLDSIM.  Blasband  and  Jafolla 
(1990)  compare  predicted  radiance  values  spectrally  across  the  2.6-3. 0  pm  band  to  A.D. 
Little  data  obtained  from  aircraft  measurements.  This  served  as  a  test  of  the  BRDFs  and 
radiance  equations,  but  did  not  test  the  processes  used  to  construct  a  cloud  altitude  map. 
Averaged  over  the  spectral  band,  the  CLDSIM  radiance  was  within  a  factor  of  2  to  4  of  the 
A.D.  Little  data,  but  it  showed  considerable  differences  when  one  examined  the  spectrum. 
CLDSIM  had  trouble  reproducing  either  the  peak  in  radiance  from  about  2.65-2.8  pm,  or  the 
region  outside  this  band.  Section  4.0  discusses  a  possible  reason  for  this. 

One  difficulty  using  the  A.D.  Little  data  was  that  little  information  was  available  to  PRA 
about  the  properties  of  the  specific  clouds  observed.  This  problem  was  ameliorated  when 
PRA  tested  CLDSIM  and  the  altitude  database  generation  process  using  NOAA  data  (Mertz, 
1 991  b).  Here  NOAA  AVHRR  data  was  used  to  construct  a  database,  and  then  CLDSIM  was 
run  to  try  to  reproduce  the  data.  Comparisons  were  done  using  bands  at  0.86,  3.71,  10.74 
and  1 1 .86  pm.  A  standard  BRDF  was  used  because  the  microphysics  of  the  cloud  scatterers 
was  not  contained  in  the  data.  The  accuracy  of  CLDSIM  was  gauged  using  the  mean, 
standard  deviation,  and  extrema  of  the  predicted  radiances,  as  well  as  the  correlation 
coefficient  between  the  data  and  the  simulated  scenes.  For  the  two  LWIR  bands  the 
agreement  was  excellent,  with  correlation  coefficients  above  99%.  This  was  expected  since 
these  bands  were  used  to  construct  the  database.  For  the  two  bands  which  contained  solar 
scattering,  the  agreement  was  good,  but  the  correlation  coefficients  dropped  to  around  50%. 
This  was  attributed  to  too  much  contrast  being  produced  by  CLDSIM  when  it  turned  on  and 
off  pixels  depending  on  their  orientation  to  the  sun  and  observer. 
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At  the  same  time,  CLDSIM  was  also  tested  against  the  absorption  band  data  from 
HIRS/2,  which  is  part  of  the  TOYS  data  product  used  to  determine  the  atmospheric  profile 
for  database  generation.  Agreement  here  was  good,  although  in  strongly  absorbing  bands 
where  one  has  trouble  seeing  to  the  cloud  layer,  CLDSIM  did  not  reproduce  the  exact 
structure  in  the  observed  data,  even  though  it  did  correctly  predict  a  low  variance.  This  is 
due  to  the  fact  that,  in  CLDSIM,  structure  comes  from  cloud  top  variations,  and  structure  in 
the  atmosphere  above  the  clouds  is  not  modeled. 

To  test  CLDSIM  in  the  SWIR  and  to  validate  the  specular  model,  PRA  collected  DSP 
returns  near  a  specular  scattering  geometry  (Shanks,  1 992a).  Coincident  GOES  and  AVHRR 
data  were  also  collected.  The  AVHRR  data  was  used  to  construct  the  BAJA  database. 
CLDSIM  was  executed  using  this  database,  and  its  predicted  radiances  were  then  run 
through  PRA's  model  of  the  DSP  sensor.  When  the  specular  model  was  turned  on,  the 
exceedance  plot  obtained  from  the  model  compared  well  with  the  data  for  large  intensities. 
For  lower  intensities,  DSP's  complex  processing  techniques  made  comparison  difficult. 
When  one  compared  the  spatial  distribution  of  returns  between  the  real  and  simulated  data, 
one  found  significant  differences.  The  DSP  returns  were  much  more  concentrated  than  the 
CLDSIM  returns. 

During  the  BASS  study,  a  further  comparison  was  done  between  CLDSIM  and  DSP  data 
(Albright,  1992).  This  comparison  was  not  a  validation  of  CLDSIM,  but  it  was  an  attempt  to 
compare  the  distribution  of  clutter  computed  using  a  standard  CLDSIM  database  with  that 
observed  by  an  operational  system.  Similar  viewing  geometries  were  used,  but  no  attempt 
was  made  to  match  cloud  type,  altitude,  cover  amount,  or  microphysics.  Further,  the  DSP 
data  sets  were  only  claimed  to  be  representative  on  the  basis  of  anecdotal  evidence. 
Comparisons  were  done  for  a  specular  geometry,  a  geometry  near  specular  and  a  diffuse 
geometry.  Exceedance  plots  showed  that  CLDSIM  predicted  more  severe  returns  for  its 
database  in  the  specular  geometry  than  the  data  showed,  while  underpredicting  the  returns 
for  the  diffuse  geometry.  These  results  may  be  affected  by  two  factors.  First,  the  CLDSIM 
scene  was  generated  with  an  unphysical  arctic  atmosphere  over  equatorial  clouds  to 
enhance  clutter.  Second,  PRA  subsequently  discovered  a  bug  in  the  MSRAT  code's 
treatment  of  gaseous  absorption,  which  has  the  effect  of  underestimating  mean  cloud 
radiance  by  a  few  percent  up  to  80%  depending  on  altitude  and  geometry. 

The  specific  details  of  the  BASS  CLDSIM  /  DSP  comparison  limits  its  usefulness  for 
making  general  statements  about  CLDSIM.  Still,  comparison  of  standard  CLDSIM  images 
to  statistically  significant  sets  of  operational  data  is  an  important  complement  to  the  cloud- 
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matched  NOAA  and  PRA  DSP  validation  efforts  reported  above.  Such  a  comparison  is 
needed  to  let  the  system  developer  know  how  many  CLDSIM  images  must  be  analyzed  to 
represent  the  range  of  expected  returns  for  a  given  scenario,  and  to  guide  PRA  in  expanding 
the  set  of  cloud  altitude  databases.  A  start  along  these  lines  is  represented  by  a  study  PRA 
performed  using  CLDSIM  to  predict  the  range  of  returns  a  BP  constellation  would  observe 
over  a  year  (Shanks,  1992b).  This  study  provides  context  so  that  the  clutter  from  an 
individual  CLDSIM  scene  can  be  compared  to  the  range  of  clutter  produced  by  CLDSIM.  A 
similar  study  could  be  done  for  the  DSP  sensor  or  for  MSX,  so  that  range  of  CLDSIM  returns 
could  be  compared  to  statistics  from  large  numbers  of  measurements  from  these 
instruments. 

Critique  of  CLDSIM  Calculational  Steps 

The  previous  CLDSIM  validation  has  shown  that  CLDSIM  produces  reasonable  radiance 
values  for  many  conditions.  However,  a  few  improvements  can  still  be  suggested. 

The  CLDSIM  methods  for  handling  cloud  illumination  and  shadowing  are  local  in  nature. 
A  pixel  is  illuminated  or  not  depending  on  its  orientation  with  respect  to  the  sun  and  the 
viewer.  Thus,  a  pixel  facing  the  sun  but  hidden  from  it  by  an  intervening  cloud  mass  is 
treated  as  if  the  mass  is  not  there.  Similarly,  pixels  receive  the  same  diffuse  radiation 
contribution  whether  they  are  illuminated  by  surrounding  clouds  or  face  into  space.  This  local 
handling  of  shadowing  and  illumination  is  a  reasonable  approximation  for  high  elevation 
angle  geometries  where  cloud-on-cloud  interactions  are  slight,  but  becomes  less  reasonable 
at  lower  elevation  angles.  It  is  recommended  that  shadowing  and  cloud-on-cloud  illumination 
be  improved  to  handle  non-local  effects.  This  might  be  done  by  generating  coarse  resolution 
representations  of  the  cloud  top  surface  to  determine  line-of-sight  intersections  with  the 
cloud,  and  finer  resolution  data  to  determine  the  fine  structure  of  scattering. 

CLDSIM  treats  scattering  as  a  surface  effect,  while  scattering  actually  takes  place 
throughout  a  volume.  The  calculations  of  CLDSIM's  BRDFs  take  this  fact  into  account  by 
computing  multiple  scattering  throughout  an  infinitely  thick  slab.  As  long  as  the  radius  of 
curvature  of  the  cloud  surface  is  large  compared  to  the  mean  free  path  between  scatters,  this 
geometry  is  accurate.  However,  closer  range  TMD  sensors  may  look  at  clouds  in  finer  detail 
and  at  lower  elevation  angles,  and  observe  structures  with  small  radii  of  curvature.  The 
protrusions  on  cumulus  clouds  serve  as  good  examples.  In  that  case,  using  BRDFs 
computed  for  spherical  scattering  volumes  may  be  more  accurate  than  the  slab  BRDFs. 
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Two  -  perhaps  offsetting  -  approximations  affect  the  accuracy  of  CLDSIM's  treatment  of 
background  radiation  from  the  terrain  below  the  cloud.  When  CLDSIM  includes  background 
radiation,  it  attenuates  it  using  beam  transmission  equations.  Thus,  L^^gis  multiplied  by  (1- 
Op)  which  is  exp  ( -c  ( z-z^J  ).  This  factor  represents  the  fraction  of  the  upwelling  radiance 
that  is  neither  scattered  nor  absorbed  as  it  passes  through  the  cloud.  However,  much  of  the 
scattered  radiance  is  scattered  in  the  forward  direction  and  passes  through  the  cloud.  The 
beam  transmission  equation  misses  this  radiance,  and  so  underestimates  the  contribution 
of  Ltjkg  to  the  final  radiance.  Simple  changes  to  the  beam  transmission  equation  could 
approximate  the  scattering  contribution.  Using  ideas  developed  in  Section  3,  the  change 
needed  is 

X  -  =  X  (13) 

Here  f  is  a  measure  of  the  fraction  of  light  scattered  in  the  forward  direction. 

Offsetting  the  increase  in  ^i^g's  contribution  obtained  if  the  suggested  approximation  is 
used  is  the  fact  that  as  the  radiance  travels  through  the  cloud  it  is  spread  out.  Thus,  the 
sharpness  of  clutter  below  the  cloud  is  reduced  by  passing  through  the  cloud.  This  reduces 
the  effect  of  background  clutter.  It  is  not  known  which  effect  predominates:  the  forward 
scattering  that  increases  the  transmitted  terrain  clutter  or  the  spreading  of  the  beam  that 
washes  it  out. 

As  mentioned  before  in  discussing  PRA's  validation  of  CLDSIM  against  NOAA  data 
(Mertz,  1991b),  CLDSIM  produces  unstructured  scenes  in  highly  absorbing  bands  which 
have  neglible  transmission  down  to  the  cloud  layer.  To  remedy  this  situation,  PRA  should 
include  atmospheric  gravity  waves  and  other  sources  of  atmospheric  structure  if  they  become 
available  in  atmospheric  state  codes. 

Critique  of  CLDSIM  in  the  SSGM 

CLDSIM  is  a  code  that  is  typically  run  in  one  of  two  ways:  it  is  run  either  as  a  stand-alone 
code  by  people  experienced  in  atmospheric  physics,  or  it  is  run  by  people  of  diverse  training 
as  part  of  the  SSGM.  There  are  significant  differences  between  these  two  ways  of  running 
CLDSIM.  When  CLDSIM  is  run  as  a  stand-alone  code,  it  often  uses  cloud  top  altitude 
databases  specifically  constructed  for  a  particular  problem,  while  the  general  user  of  CLDSIM 
must  use  one  of  the  seventeen  pre-set  databases.  Very  little  information  is  provided  in  the 
SSGM  about  the  meterology  represented  in  the  databases,  and  the  range  of  conditions  each 


22 


one  is  good  for.  The  CLDSIM  user  is  thus  left  wondering  which  clouds  can  legitimately  be 
used  in  a  particular  scenario,  and  whether  the  databases  in  the  SSGM  span  the  likely  cloud 
cover  one  could  expect.  In  addition,  there  is  minimal  error  checking  in  the  SSGM  to  make 
sure  that  consistent  sets  of  inputs  are  used.  Such  error  checking  is  crucial  to  insure  that  time 
and  money  is  not  needlessly  spent  analyzing  inaccurate  results.  In  addition,  any  warnings 
that  CLDSIM  does  give  should  be  transmitted  with  the  image,  perhaps  by  placing  them  in  the 
image's  header.  During  the  BASS  study,  this  would  have  helped  remind  users  that  several 
of  the  images  were  clutter-enhanced  due  to  a  choice  of  an  unphysical  atmosphere  profile. 
Increased  error  checking,  warning  messages,  and  on-line  documentation  are  scheduled  to 
be  incorporated  into  future  releases  of  the  SSGM.  Physically  based  input  checks  and  on-line 
help  for  using  cloud  databases  should  be  aggressively  pursued  for  early  inclusion  in  the 
SSGM. 

Another  feature  that  reduces  CLDSIM's  utility  in  the  SSGM  is  its  slow  running  time. 
Typical  run  times  are  30  minutes  to  2.5  hours  on  a  SGI  4D-25  for  a  reasonably  sized  cloud 
image.  CLDSIM  has  an  architecture  that  causes  it  to  compute  facet  normals  or  scattering 
angles  for  all  pixels  in  a  cloud  altitude  database,  whether  the  pixels  are  to  be  part  of  the  final 
image  or  not.  Thus,  it  takes  about  the  same  time  to  generate  a  cloud  image  of  a  few  dozen 
square  kilometers  as  it  does  to  make  an  image  covering  the  region  from  Mexico  to  Alaska. 
CLDSIM  is  being  rewritten  to  meet  new  timing  requirements,  and  a  feature  is  being  added 
to  allow  one  to  cut  out  a  small  region  of  interest  from  a  large  cloud  database  before 
processing  begins.  A  reorganization  of  data  in  CLDSIM  is  also  being  planned.  While  it  is 
impossible  to  judge  the  time  savings  these  changes  will  make  before  they  are  fully 
implemented,  if  significant  time  savings  occur,  they  will  make  CLDSIM  a  much  more  valuable 
tool.  When  scenes  are  relatively  easy  to  produce,  engineering  studies  of  the  variation  of 
returns  with  solar  position  and  atmospheric  condition  will  be  attractive  to  the  general  CLDSIM 
user. 

Because  CLDSIM  has  been  slow  in  the  past,  PRA  has  implemented  a  zeroth-order 
method  of  allowing  cloud  images  to  change  with  time.  A  time  series  of  cloud  images  are 
calculated  assuming  the  solar  and  observer  positions  are  fixed  in  time.  Thus,  temporal 
variations  in  cloud  scenes  come  from  changes  in  the  observer  position  that  is  given  to 
footprinting  routines,  rather  than  changes  in  the  angles  used  in  the  radiance  calculating 
routine  CLDRAD.  To  see  what  effect  this  approximation  has  on  a  simulation,  Visidyne  ran 
a  case  with  specular  scattering  off  of  the  BAJA  databases  at  low  elevation  angles  (25°).  The 
specular  scattering  model  was  used  because  of  the  narrow  peak  of  the  BRDF  in  this  model. 
Parameters  were  chosen  to  approximate  a  BE-like  sensor.  Scenes  were  generated  two  per 
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second  for  a  time  sequence  of  10  seconds  using  the  single-time  approximation.  Then  two 
consecutive  frames  were  reproduced  using  separate  SSGM  runs.  Consecutive  frames  were 
differenced,  and  the  two  difference  images  -  one  from  the  time  series  and  the  other  from 
separate  runs  -  were  compared,  both  visually  and  using  their  exceedance  plots.  Because 
of  the  over  2000  km  range  between  the  sensor  and  the  cloud,  and  the  fast  frame  rate,  no 
significant  difference  was  observed  between  the  two  methods  of  calculating  the  scenes. 
Although  a  simple  time  interpolation  method  probably  should  be  added  to  CLDSIM,  and 
doing  so  would  not  be  very  difficult,  this  single  test  case  does  not  provide  compelling 
evidence  that  it  is  necessary. 

Planned  PRA  Improvements  to  CLDSIM 

CLDSIM  is  being  extensively  rewritten  for  Release  6.0  of  the  SSGM  (due  April  1994). 
The  input  files  to  CLDSIM  are  being  reorganized  to  group  data  differently,  and  the  code  is 
being  streamlined  for  speed.  The  ability  to  select  just  a  section  of  a  large  altitude  database 
for  processing  will  be  added  through  CLDSIM  "cookie  cutter"  capability.  Also,  a  capability 
will  be  added  to  allow  the  user  to  tile  a  region  with  replicas  of  a  single  cloud  database  to 
cover  cases  such  as  observing  a  long  missile  fly-out  with  a  small  FOV. 

A  major  goal  for  Release  7.0  (late  1994)  is  to  replace  pixels  in  the  cloud  databases  with 
triangular  facets,  which  are  easier  for  SGI  hardware  to  handle.  Transforming  from  pixels  to 
facets  will  allow  the  user  to  vary  the  resolution  of  the  database  for  increased  throughput.  For 
instance,  high  resolution  sections  of  the  database  could  be  placed  around  regions  of  interest 
in  a  cloud  scene  (say  near  a  target  being  tracked),  while  lower  resolution  representations 
could  be  used  elsewhere. 

The  facet  model  will  also  be  used  to  improve  the  cloud  shadowing.  Facets  will  be  ordered 
by  distance  away  from  the  sun,  and  facets  with  more  than  50%  of  their  area  obscured  by 
other  facets  will  be  in  shadow.  Facets  will  then  be  ordered  by  distance  from  the  observer, 
and  unobscured  facets  will  be  projected  onto  the  final  image.  This  does  not  seem  to  cover 
the  issues  of  cloud-on-cloud  illumination  and  backlighting  of  surfaces,  but  it  is  a  start. 

APART  is  to  be  replaced  in  Release  6.0  with  the  MOSART  atmospheric  transport  code. 
A  three-stream  cloud-over-terrain  model  will  be  implemented  which  takes  into  account  the 
exchange  of  radiation  between  these  features.  A  three-stream  cloud-over-cloud  model  will 
come  in  Release  7.0.  In  addition,  the  cylindrical  geometry  assumed  in  the  present 
footprinting  routines  will  be  replaced  by  a  full  3-D  algorithm. 


24 


3.  VISIDYNE  CLOUD  SCATTERING  MODEL 


In  order  to  test  the  CLDSIM’s  BRDFs,  Visidyne  adapted  the  radiation  transport  code  used 
by  NORSE  and  its  predecessors  to  compute  BRDFs  for  various  particle  size  distributions  and 
cloud  types  (Ewing,  1978).  The  code  consists  of  MIECODE,  a  Mie  scattering  routine  to 
compute  the  phase  function  of  a  given  particle  distribution,  and  SLAB,  a  routine  that 
approximates  multiple  scattering  in  a  slab  of  given  thickness.  They  are  joined  together  in  the 
program  MSLAB.  The  routines  are  described  in  the  next  section,  which  is  followed  by  reports 
on  the  validation  of  MSLAB  and  computations  testing  CLDSIM's  BRDFs. 

3.1  Description  of  MSLAB 

Visidyne's  MIECODE  is  a  standard  Mie  code  that  calculates  the  phase  function  p(a), 
scattering  coefficient  kg  and  absorption  coefficient  k^  for  a  distribution  of  spherical  droplets. 
The  inputs  are  the  complex  index  of  refraction  at  the  wavelength  of  interest  and  parameters 
characterizing  the  droplet  distribution.  Although  several  distributions  are  available, 
MIECODE  was  modified  to  follow  PRA's  practice  of  representing  the  cloud  droplet  distribution 
as  a  modified  gamma  distribution  defined  over  a  range  of  radii  between  r^^  and  . 
Throughout  that  range  the  number  of  drops  per  cubic  centimeter  with  radius  r  is  given  by 


Here  Nj  gives  the  total  number  of  drops  per  cubic  centimeter  and  A  is  a  normalization 
constant  that  depends  on  r„,j„  and  If  these  are  set  to  zero  and  infinity  respectively,  A  is 
given  by 


where  T  is  the  gamma  function.  The  quantities  Tq,  a  and  y  determine  the  distribution's  shape. 


SLAB  approximates  multiple  scattering  in  a  slab  of  a  given  thickness  using  single 
scattering  enhanced  by  estimates  of  the  multiple  scattering  contribution.  To  see  how  this  is 
done,  let  L(s,Q)  represent  the  radiance  along  a  path  at  pathlength  s,  radiating  in  the  direction 


dL 

ds 


=  -k  L+J 

e 


(16) 
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W,  where  W  can  be  described  by  the  spherical  coordinates  9  and  4).  As  it  propagates,  the 
radiation  suffers  extinction  governed  by  the  coefficient  kg,  and  picks  up  radiance  due  to  the 
scattering  of  light  into  the  Q  direction,  represented  by  the  source  term  J.  The  radiation 
transport  equation  has  the  solution 


L ( s,  Q)  -L(s^,Q)  e 


-k^{s-sj 


■/ 


(17) 


where 
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Consider  light  scattered  off  of  a  cloud  top.  Let  z  measure  the  distance  down  from  the  top  of 
the  cloud,  which  has  a  vertical  thickness  of  I,  and  let  s  be  at  the  cloud  top,  where  z=0.  Then 


(s-s)= - la^cosO) 

cos  (9)  1-1 


:i9: 


Let  L(Q)  =  L(0,Q)  be  the  radiation  coming  out  of  the  cloud  in  the  O  direction.  Switching  from 
s  to  z,  and  ignoring  the  upwelling  background  radiation  contained  in  the  L(So,0)  term  gives 


k  z 


L(Q)  e  ^  ^ 


(20) 


The  Le^,(s,Q')  term  in  equation  3.1.5  contains  light  that  has  been  multiply  scattered,  as 
well  as  single  scattered  light.  The  contribution  to  the  cloud  top  radiance  of  single  scattered 
light  is  easy  to  calculate.  If  the  light  at  the  top  of  the  cloud  comes  in  from  the  Qg  direction, 
the  illuminating  light  at  the  top  of  the  cloud  is  given  by 

Lg  (  0  ,q0  =Jg5  (cos  (90  -cos  (9^)  )  5  ((t)^-^^)  (21) 

Applying  the  attenuation  factor  exp{-  kg  z  /  p')  to  get  the  amount  of  the  illuminating 
radiation  that  does  not  scatter  until  reaching  the  z  level,  and  integrating  over  O'  gives 
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(22) 
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Here  a  is  the  scattering  angle  between  Q  and  Q’.  The  expression  for  the  single  scattered 
outgoing  radiance  is 


00. 


ss  .  4n  ° 


Ur 


U+Ur 


-kj- 


1-e 


Wo 


(23) 


To  estimate  the  multiple  scattering  contribution,  SLAB  follows  the  NORSE  code  and 
defines  a  build-up  factor  B(z)  that  estimates  the  ratio  of  the  multiply  scattered  radiation  from 
the  z  level  to  the  single  scattered  radiation.  To  define  B,  consider  the  fraction  fg  of  light  single 
scattered  at  z  that  escapes  out  of  either  the  cloud  top  or  bottom  without  scattering  again. 

{ J  (  z ,  o')  e  ^  dQ^ 


For  simple  geometries,  such  as  a  slab  geometry,  fg  can  be  evaluated  analytically. 


Of  the  radiation  first  scattered  at  z,  the  fraction  fg  escapes  without  further  interactions, 
while  the  fraction  f,  =  (1-fg )  either  is  absorbed  or  scattered.  SincegCO  gives  the  ratio  of 
scattering  to  extinction,  the  fraction  cOg  f,  of  the  light  survives  the  second  scattering  without 
being  absorbed,  and  the  fraction  cOg  f^  fg  escapes  the  cloud.  In  the  same  way,  the  fraction  of 
the  light  that  escapes  after  scattering  n  times  is  (cOg  fg.  Summing  up  the  contributions 
and  dividing  by  the  fraction  escaping  after  only  one  scatter  gives  the  build-up  factor 


Biz)  =k  4(c0gf^)"-^ 


:i-f^C0g)  (l-(l-f^)a)g) 


(25) 
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The  amount  of  multiple  scattered  light  can  be  estimated  using  the  build-up  factor.  The 
next  question  to  decide  is  how  to  include  this  light  in  the  outgoing  radiation.  The  Rayleigh 
scattering  pattern  holds  for  radiation  scattered  off  of  droplets  small  compared  to  the 
wavelength  (x  =  2nr/A  «  1)  and  is  approximately  isotropic.  (Rayleigh  scattering  goes  as 
(1+cos^(a))/2,  giving  a  factor  of  two  variation.)  Scattering  from  large  droplets  (x  »  1)  has 
a  pattern  that  is  highly  forward  peaked.  To  determine  how  peaked  the  scattering  is,  the 
SLAB  code  uses  the  forward  directivity  integral  of  the  Mie  phase  function,  defined  by 


1 

Jpia) cos (a) dcos (a) 

-1 


(26) 


It  then  approximates  the  phase  function  by  assuming  that  a  fraction  of  the  light  given  by  f  is 
scattered  in  the  forward  direction  and  that  the  rest  of  the  light,  (1-f),  is  scattered  isotropically. 
In  the  interaction  represented  by  equation  3.1 .3,  the  extinction  term  k^  L  is  the  sum  of  the  part 
ka  L  that  is  absorbed  and  the  part  k^  L  (  =  cOq  k^  L)  that  is  scattered.  SLAB  assumes  that  the 
fraction  f  of  scattered  light  is  scattered  precisely  in  the  forward  direction.  This  is  handled 
mathematically  by  adding  back  on  the  right  hand  side  of  equation  3.1 .3  the  amount  k^  f  L. 

(3.Tj 

—  =-k^L  +  J+k^fL=-k^{l-(S)^f)L  +  J  (27) 

The  effect  of  this  is  to  replace  the  extinction  coefficient  kg  in  the  radiation  transport  equation 
with  the  quantity  kg  (1  -  cOof). 

With  these  approximations,  NORSE  calculates  the  cloud  top  radiance  as  a  sum  of  single 
scattered  and  multiple  scattered  radiance 


L(Q)=L^^(Q)+L^JQ) 


(28) 


where 
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and 
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In  the  above,  the  term  -1  occurs  in  the  factor  B-1  to  remove  single  scattering  from  the 
multiple  scattering  factor  and  (1-f)  is  used  to  give  the  fraction  of  the  scattered  radiation  that 
has  not  been  assigned  to  the  forward  direction.  The  phase  function  for  isotropic  scattering 
is  unity. 

The  Mie  and  SLAB  codes  are  combined  in  the  MSLAB  routine  to  take  as  inputs  cloud 
droplet  distribution  parameters  and  cloud  altitudes,  and  to  give  as  output  BRDFs  for  chosen 
wavelengths  and  scattering  geometries.  COg  and  HgO  gaseous  absorption  inside  the  cloud 
is  handled  using  a  weak  line  approximation.  The  amount  of  these  gases  is  determined  by 
computing  the  partial  pressures  of  these  gases  in  an  atmosphere  with  a  constant  scale 
height  and  lapse  rate.  The  water  vapor  is  assumed  to  be  at  100%  relative  humidity. 

3.2  Validation  of  MSLAB  BRDF  Calculations 

To  gain  confidence  that  the  MSLAB  code  could  accurately  calculate  BRDF's,  several 
test  cases  were  run.  The  tests  include  calculating 

(1)  the  slab  scattering  BRDF  using  a  simple  phase  function; 

(2)  the  Mie  theory  phase  function; 

(3)  BRDFs  as  a  function  of  optical  depth; 

(4)  BRDFs  as  a  function  of  particle  size;  and 

(5)  BRDFs  with  and  without  gaseous  absorption. 
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Figure  3.  Comparison  of  MSLAB  calculations  to  Chandraskhar ' s 
exact  results. 
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Calculation  of  the  Phase  Function 


Further  work  was  done  to  compare  MSLAB  to  an  extensive  set  of  calculations  by  Hansen 
(Hansen,  1971).  Hansen  combined  Mie  calculations  with  a  doubling-method  slab  treatment 
to  calculate  phase  functions,  reflected  radiance  levels,  and  polarizations  from  clouds.  Since 
his  interest  was  in  finding  ways  of  using  reflected  sunlight  to  determine  cloud  microphysical 
properties,  he  chose  for  his  calculations  wavelengths  in  the  shorter  end  of  the  IR  and  in 
window  regions.  His  four  wavelengths  were  at  1.2,  2.25,  3.1  and  3.4  pm.  For  his  cloud 
droplet  distributions  he  used  the  gamma  distribution,  which  is  obtained  from  the  modified 
gamma  distribution  by  setting  y  to  1.  He  also  parameterized  the  distribution  using  the 
quantities  Rg,,  and  a\„,  which  also  appear  as  a  and  b  in  his  paper.  Rg„  is  the  mean  droplet 
radius,  averaged  over  radius  with  the  weighting  function  nr^  n(r).  is  the  variance.  They 
can  be  converted  to  the  modified  gamma  distribution  parameters  and  a  using  the  following 
relationship 


r 


eff 


(31) 


To  test  the  Mie  scattering  section  of  MSLAB,  we  reproduced  Hansen's  calculations  of  the 
single  scattering  albedo  and  forward  directivity.  Table  4  shows  Hansen's  results.  The 
calculations  are  done  at  the  four  different  wavelengths  and  at  four  different  values  of  For 
each,  o^gf,  =  1/9.  Table  5  shows  the  results  from  MSLAB.  Comparing  the  two,  one  sees  that 
the  disagreement  in  albedo  and  forward  directivity  between  the  two  codes  is  less  than  about 
1%.  The  agreement  could  be  easily  improved  by  increasing  the  angular  resolution  at  which 
MSLAB  calculates  the  phase  function. 

Further  verification  of  the  Mie  code  is  shown  in  Figs.  4  -  7,  where  the  phase  functions 
from  MSLAB  are  compared  at  two  wavelengths  to  those  of  Hansen.  Figure  4  shows 
Hansen's  plots  for  four  different  Rg„'s.  The  plots  are  displaced  from  each  other  by  one  order 
of  magnitude  for  clarity.  The  short  horizontal  bars  found  on  the  curves  mark  where  each 
crosses  unity.  At  1 .2  pm,  the  complex  part  of  the  index  of  refraction  is  small,  so  there  is  little 
absorption  inside  the  droplet.  The  phase  function  shows  a  strong  forward  diffraction  peak, 
along  with  peaks  at  around  140'^  and  1 80'"  scattering  angle,  corresponding  to  the  rainbow  and 
glory  features.  Since  rainbows  are  due  to  geometric  optics  effects,  they  are  expected  to  be 
more  pronounced  for  larger  drops. 
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The  MSLAB  calculations  in  Figure  5  show  that  MSLAB  reproduces  the  drop  in  the  phase 
function  to  a  minimum  and  the  rise  up  to  the  glory  at  180°.  The  rainbow  shows  up  clearly  in 
the  1 2  and  24  //m  curves  as  well.  Overall  the  phase  function  magnitudes  compare  well,  even 
at  the  0°  peak.  One  feature  that  is  not  well  reproduced  is  the  sharpness  of  the  forward  peak. 
This  is  due  to  the  fact  that  the  calculations  were  done  at  21  scattering  angles  whose  cosines 
are  equally  spaced  by  0.1  from  1  to  -1.  With  the  first  two  angles  at  0  and  25  degrees, 
MSLAB  lacks  the  resolution  to  pick  up  the  sharp  peak  at  0  degrees.  A  slight  modification  of 
MSLAB  could  produce  greater  resolution.  It  should  be  pointed  out  that  when  MSLAB 
performs  its  scattering  calulations,  it  modifies  the  0°  part  of  the  phase  function  to  have  a 
value  closer  to  Hansen's  values  at  around  10°.  This  is  appropriate  since  extreme  forward 
scattering  is  handled  by  modifying  the  extinction  coefficient,  as  explained  above. 

At  3.1  /^m,  the  complex  index  is  comparatively  large,  and  there  is  little  structure  in  the 
phase  function  except  for  the  forward  peak.  The  MSLAB  results  in  Figure  7  show  the  same 
general  features  as  Hensen's  results  in  Figure  6.  The  magnitudes  compare  well,  and  the 
increase  in  slope  in  the  forward  peak  with  increasing  Rgf,  is  represented.  The  resolution  in 
MSLAB  below  25°  is  still  less  than  one  would  like. 


Table  4.  Hansen's  Phase  Function  Results  (Adapted  from  Hansen's  Table  2.) 


Wavelength  (//m) 

1.2 

2.25 

3.1 

3.4 

Index  of  Refraction 

J1 _ 

1.323 

1.290 

1.426 

1.449 

Jh _ 

9.74  X  10  ® 

3.04  X  lO  "* 

.1828 

.01888 

_ _ 

3 

.999706 

.996541 

.5148 

.8661 

6 

.999379 

.9890757 

.4909 

.7285 

12 

.998818 

.981374 

.5115 

.6289 

24 

.988038 

.969260 

.5264 

.5668 

<  cos  a  > 

3 

.7804 

.8412 

.8843 

.7659 

6 

.8311 

.8016 

.9308 

.7910 

12 

.8550 

.8495 

.9479 

.8898 

24 

.8677 

.8720 

.9523 

.9336 
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Table  5.  IWSLAB's  Phase  Function  Results 


Figure  4.  Hansen  phase  functions  at  1.2  microns.  Note  that  the  horizontal  hars  are 
where  each  plot  cross  unity.  (Hansen’s  Fig.  3) 


Figure  6.  Hansen  phase  functions  at  3.1  microns.  Note  that  the  horizontal 


bars  are  where  each  plot  cross  unity  (Hansen's  Fig.  6) 
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MSLAB  Phase  Functions  at  3.1  microns 


Hansen's  R  effective 


3  microns 
10  X  (6  microns) 

100  X  (12  microns) 
1000  X  (24  microns) 


Figure  7.  MSLAB  phase  functions  at  3.1  microns 


Optical  Depth  Variations 

Figures  8  through  13  compare  the  BRDF  values  calculated  for  different  optical  depths  by  Hansen 
and  MSLAB.  The  Hansen  calculations  were  done  using  Reff=  6  and  =  1/9,  while  MSLAB 
used  a  distribution  that  PRA  has  employed  in  the  past  to  model  altostratus  clouds:  =  6.49 

A^m  and  o^eff  =  08.  (Mertz,  1991a).  All  calculations  were  done  at  0  solar  zenith  angle. 
Figure  8  shows  Hansen's  reflected  intensity  results  at  1.2  /^m.  The  normalization  of  his 
results  is  such  that  it  is  equal  n  times  a  BRDF.  Figure  9  shows  the  MSLAB  results  suitably 
normalized  for  comparison.  The  rainbow  peak  in  the  phase  function  at  about  140°  scattering 
angle  shows  up  as  a  peak  in  the  BRDF  at  around  40°  observer  zenith  angle  for  small  optical 
depths  in  both  figures.  This  feature  is  washed  out  as  the  optical  depth  increases.  Figure  9 
also  shows  CLDSIM's  alto4.db  BRDF  at  its  nearest  wavelength  to  1 .2  /im.  The  curve  shows 
that  the  CLDSIM  BRDF  corresponds  to  a  large  optical  depth  cloud.  (The  alto4.db  file  gives 
the  optical  depth  as  about  44  for  this  wavelength.) 

Figure  10  shows  Hansen's  results  at  3.1  ij.m.  The  smoothness  of  the  phase  function  at 
this  wavelength  is  reflected  in  the  smoothness  of  the  BRDF.  The  peaking  of  the  BRDF  at  90° 
observer  zenith  angle  -  especially  for  small  optical  depth  -  is  the  result  of  reflection  off  of  the 
water  droplets.  These  features  show  up  in  MSLAB's  results  in  Figure  1 1 .  The  curves  from 
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Figure  8.  Hansen  optical  depth  variations  at  1.2  microns  (Hansen's  Fig.  7) 

CLDSIM's  alto4.db  at  two  bounding  wavelengths  are  also  shown  and  compare  well  to 
MSLAB.  Close  examination  of  the  ordinates  of  Figs.  10  and  11  show  a  factor  of  ten 
difference  between  Hansen  on  the  one  hand  and  CLDSIM  and  MSLAB  on  the  other.  Due 
to  the  close  agreement  of  the  later  two  codes,  there  is  likely  to  be  a  typographical  error  in 
Hansen's  plot.  Figures  12  and  13  show  Hansen's  and  MSLAB's  results  at  the  nearby 
wavelength  of  3.4  //m.  The  agreement  is  good  except  at  small  zenith  angles  where  MSLAB 
needs  more  resolution. 

Particle  Size  Variations 


Hansen  investigated  the  effect  of  changing  the  particle  size  distribution  on  BRDFs. 
Figures  14  and  16  show  his  results  for  distributions  which  have  the  same  value  of  1/9, 
but  differ  in  their  Rg„  parameter,  which  appears  as  "a"  on  the  plots.  The  optical  depth  is  32 
for  each  curve.  Since  this  value  corresponds  to  a  thick  cloud,  variations  seen  in  these  plots 
can  be  viewed  as  conservative.  At  1.2  ^^m,  one  sees  the  rainbow  peak  become  visible 
around  40°  observer  zenith  angle  for  the  large  droplet  distributions.  For  these  distributions, 
the  scattering  is  sufficiently  into  the  geometric  optics  regime  to  allow  the  rainbow  to  appear 
even  for  thick  clouds.  Figure  15  shows  the  MSLAB  results,  which  agree  well  for  sizes  below 
24  //m. 
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Figure  9.  MSLAB  optical  depth  variations  at  1.2  microns 


Figure  10.  Hansen  optical  depth  variations  at  3.1  microns  (Hansen's  Fig.  10) 


Figure  12.  Hansen  optical  depth  variations  at  3.4  microns  (Hansen's  Fig.  11) 
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Figure  13.  MSLAB  optical  depth  variations  at  3.4  microns 


Figure  14.  Hansen  particle  size  variations  at  1.2  microns  (Hansen's  Figure  20.) 
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BRDFs  for  various  particle  radii  (0  Solar  Zenith,  microns) 


Hensen's  R  effective 


3  microns 
6  microns 
12  microrK 
24  microns 


Figure  15.  MSLAB  particle  size  variations  at  1.2  microns 
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Figure  16  shows  Hansen's  results  at  3.4  yum.  The  decrease  in  BRDF  with  inceasing  Rg,, 
comes  from  the  greater  absorption  of  light  traveling  through  larger  droplets.  The  SLAB 
results  in  Figure  17  reproduce  the  flat  distribution  of  R^^  =  3  mhi,  and  the  rising  tails  of  the 
other  distributions.  The  plot  lacks  enough  angular  resolution  below  25°  to  pick  up  the 
structure  seen  in  Hansen's  work. 
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Gaseous  Absorption 


Hansen’s  work  emphasized  window  regions  without  significant  gaseous  absorption.  It  is 
important  to  validate  MSLAB  in  absorbing  regions.  To  date,  the  only  validation  that  has  been 
done  has  been  to  follow  PRA’s  lead  and  compare  MSLAB  to  the  work  of  Futterman  that  is 
cited  in  (Mertz,  1991a).  In  that  paper,  a  calculation  of  the  BRDF  of  a  Fair  Weather  Cumulus 
cloud  at  2.7  pm  is  shown  with  and  without  gaseous  absorption  included.  It  is  reproduced 
here  in  Figure  1 8,  while  Figure  1 9  shows  the  MSLAB  results.  Both  show  that  the  major  effect 
of  adding  gaseous  absorption  at  this  wavelength  is  to  reduce  the  value  of  the  BRDF  by  a 
factor  of  about  4  for  Futterman's  results  and  about  2.5  for  MSLAB,  without  significantly 
affecting  its  angular  dependence.  Besides  this,  there  is  some  difference  between  the  overall 
level  of  the  MSLAB  BRDF  and  that  of  Futterman. 

Two  conditions  may  help  to  explain  this  difference.  First,  there  was  not  enough 
information  provided  in  PRA's  paper  to  reproduce  the  particle  distribution  of  the  Futterman 
cloud.  MSLAB  used  instead  a  standard  particle  distribution  that  PRA  has  employed  in  the 
past  to  represent  cumulonimbus  clouds  (72  drops/cm®,  Rg„  =  14,  a  =  .113),  even  though 
it  did  not  compare  closely  with  the  information  provided  about  Futterman’s  distribution.  Using 
this  distribution,  MSLAB  predicted  a  single  scattering  albedo  (without  gaseous  absorption) 
of  0.53,  which  is  smaller  than  Futterman's  value  of  0.76.  This  suggests  that  the  MSLAB 
distribution  will  produce  lower  BRDFs  than  Futterman  predicts  even  before  gaseous 
absorption  is  considered. 

Another  factor  that  may  effect  the  result  is  that  CLDSIM’s  BRDFs  are  computed  by 
expressing  gaseous  absorption  as  a  series  of  exponentials,  each  containing  a  different 
gaseous  absorption  coefficient.  A  BRDF  is  computed  for  each  term  in  the  series,  and  they 
are  averaged  to  produce  the  final  result.  (See  equations  4  and  5)  MSLAB  only  uses  a  one- 
exponential  approximation,  although  going  to  multiple  exponentials  would  not  be  difficult  to 
do.  In  sum.  Figs.  18  and  19  show  that  MSLAB  predicts  reasonable  BRDFs  in  absorption 
bands,  although  it  is  not  fully  validated  there. 

Conclusion 

The  validation  of  MSLAB  has  shown  that  its  Mie  code  is  able  to  reproduce  phase 
functions  and  albedos  to  a  degree  of  accurary  presently  limited  only  by  the  its  angular 
resolution.  The  validation  has  also  shown  that  MSLAB  can  reproduce  the  dependence  of 
BRDFs  on  wavelengths  and  particle  sizes.  Although  its  treatment  of  gaseous  absorption  is 
not  fully  validated,  MSLAB  does  produce  reasonable  results  in  absorption  regions. 
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Figure  18.  Futterman's  BRDFs  with  and  without  gaseous  absorption 
(From  Mertz,  1991a,  Fig.  4.28) 
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3.3  Critique  of  PRA  BRDF  Methods 


Small  Optical  Depth  Treatment 

PRA's  MSRAT  BRDFs  are  calculated  for  clouds  with  large  optical  depths.  Lines-of-sight 
through  clouds  to  the  ground  may  have  small  optical  depths,  either  because  they  intersect 
a  thin  cloud  "puff"  or  the  edge  of  a  thick  cloud.  In  addition,  if  lower  elevation  geometries 
become  more  important,  the  shadowing  of  parts  of  one  cloud  by  another  can  occur,  in  which 
case  shorter  path  lengths  and  small  optical  depths  come  into  play. 

Because  each  of  CLDSIM's  BRDFs  is  precomputed  at  one  optical  depth,  CLDSIM 
handles  small  optical  depths  using  the  simple  formula 

p^=(l-e"')p  (32) 

Figures  20  and  21  compare  this  method  with  calculations  done  using  MSLAB.  The 
MSLAB  BRDFs  were  made  using  gamma  distribution  parameters  for  an  altostratus  cloud  and 
represent  the  situation  shown  in  Hansen's  Figs.  8  and  10  above.  Note  that  at  1 .2  pm,  the 
MSLAB  results  show  much  more  structure  around  the  rainbow  position  for  small  optical  depth 
than  for  large.  The  effect  of  CLDSIM's  approximation  is  simply  to  translate  the  large  optical 
depth  BRDF  to  smaller  values  in  a  log  plot.  Thus,  this  method  does  not  change  the  BRDF's 
shape  to  show  more  structure.  Note  also  that  the  overall  separation  between  the  curves  with 
optical  depth  0.25,  1,  and  8  is  much  greater  than  the  separation  predicted  by  CLDSIM's 
approximation.  As  a  sensor  scans  over  an  area  with  clouds,  it  will  see  jumps  in  radiance  as 
the  iine-of-sight  enters  or  leaves  a  cloud.  These  jumps  will  be  smoothed  out  some  by  the 
decreased  opacity  of  the  cloud  near  the  edges.  By  overpredicting  the  radiance  for  small 
optical  depths,  CLDSIM  accentuates  the  cloud/non-cloud  transition,  and  increases  the 
predicted  clutter  for  the  sensor. 

Figure  21  shows  the  results  at  3.4  pm.  At  this  wavelength,  absorption  inside  water 
droplets  produces  a  smoother  and  dimmer  BRDF.  The  smoothness  of  the  BRDF  makes 
CLDSIM's  approximation  more  appropriate  here  than  at  1.2  pm,  although  CLDSIM  still  does 
not  predict  the  increase  in  the  fraction  of  radiance  at  90°  observer  zenith  angle  seen  at 
smaller  optical  depths.  Because  of  the  smooth  BRDF  and  the  drop  off  in  solar  inradiance  at 
this  wavelength,  conditions  at  3.4  pm  are  not  as  stressing  to  a  sensor  as  conditions  at  1 .2 
pm. 
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Optical  Depth 
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4.  CORRELATED  LINE  TRANSMISSION  EFFECTS 


Our  review  of  CLDSIM  modeling  noted  the  careful  treatment  of  atmospheric  absorption. 
The  spectral  bands  selected  for  a  number  of  important  satellite  surveillance  systems  are 
centered  in  the  strong  atmospheric  absorption  bands  of  CO2  and  HgO.  There  are  a  variety 
of  reasons  for  this,  not  the  least  of  which  is  the  desire  to  eliminate  clutter  from  the  earth 
surface.  In  any  case,  determination  of  the  transmission  in  such  spectral  regions  poses  a 
significant  challenge  to  the  modeller. 

CLDSIM  utilizes  the  band  model  program  APART  to  calculate  the  transmission  through 
the  atmosphere  along  the  "dogleg”  paths  from  the  sun  to  cloud  surface  and  from  cloud 
surface  to  observer.  Note  that  the  transmission  cannot  be  calculated  for  each  segment  of  the 
dogleg  path  and  then  multiplied  since  the  (inherent)  spectral  average  does  not  commute  with 
the  path  integral.  CLDSIM  actually  uses  a  set  of  such  dogleg  paths  spanning  the  range  of 
possible  cloud  surface  facet  locations.  CLDSIM  interpolates  this  database  for  each  specific 
cloud  scattering  facet  location. 

Although  CLDSIM  treats  solar  scattering  as  a  surface  phenomenon,  it  is  in  fact  a  volume 
one.  Recognizing  this,  the  CLDSIM  developers  included  gaseous  (vapor)  absorption  in  the 
calculation  of  the  cloud  BRDFs.  At  Visidyne's  review  meeting  with  them  they  indicated  that 
without  the  vapor  absorption  the  predicted  radiances  were  much  too  high  in  calculations  for 
absorption  band  regions. 

In  CLDSIM,  the  cloud  vapor  absorption  is  treated  independently  of  the  atmospheric 
absorption,  thereby  in  effect  multiplying  the  transmissions.  Multiplication  of  transmissions 
ignores  the  correlation  of  absorption  lines  in  the  segments  involved  and  leads  to  an 
overestimate  of  the  absorption  loss.  This  can  be  seen  in  Figure  22  which  shows  one  of  the 
CLDSIM  validation  plots,  redrawn  from  Figure  1 1  of  Blasband  and  Jafolla  (1990).  The  cloud 
is  a  cirrus  cloud  at  1 1  km  altitude.  The  zenith  angle  of  the  sun  is  59°  and  that  of  the  observer 
is  80°.  The  authors  note  that  the  band  integrated  radiances  compare  reasonably  well,  6.4  x 
1 0"^  W/cm^/sr  for  the  A.D.  Little  data  versus  9.2  x  1 0'^  for  the  CLDSIM  calculation.  However, 
CLDSIM  overestimates  the  depth  of  the  absorption  in  the  band  centers,  a  fact  that  is 
consistent  with  the  neglect  of  the  correlation  of  absorption  in  the  atmosphere  and  cloud 
vapor. 

To  estimate  the  magnitude  of  the  error  in  neglecting  the  correlation  of  atmospheric  path 
and  cloud  vapor  absorption,  Visidyne  used  the  ATHENA  LTE  band  model  code 
(DeVore,1987)  to  model  two  simple  cases  involving  clouds  at  5  and  11  km  altitude.  We 
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assumed  a  vertical  path  down  through  the  atmosphere,  a  specific  distance  through  the  cloud, 
and  then  back  vertically  up  through  the  atmosphere.  We  compared  calculations  of  the 
transmissions  for  paths  in  the  cloud  only,  down  and  up  through  the  atmosphere  only,  and 
through  the  atmosphere  and  the  cloud.  The  results  are  presented  below. 


2.64  Wavelength  (ji)  2.98 


Figure  22.  Comparison  of  CLDSIM  calculation  with  A.D.  Little  aircraft 
data,  redrawn  fromBlasband  and  Jafolla  (1990). 


5  Km  Cloud  Case 


For  the  first  case  we  considered  a  typical  cloud  at  5  km  altitude.  Figure  23  shows  altitude 
profiles  of  the  primary  atmospheric  absorbers  in  the  SWIR  and  the  atmospheric  temperature. 
The  path  length  in  the  cloud  is  selected  so  that  the  absorption  in  the  band  centers  is 
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approximately  a  tenth,  as  shown  in  Figure  24.  This  figure  also  shows  the  absorption  in  the 
atmosphere  and  in  the  combined  atmosphere-cloud  system.  Note  that  the  transmission 
differences  in  the  band  centers  between  the  atmosphere  only  and  the  combined  atmosphere- 
cloud  system  are  less  than  the  cloud  only  transmission.  Because  of  this,  the  process  of 
treating  the  cloud  and  atmospheric  transmission  as  uncorrelated  by  simply  multiplying  them 
together  underestimates  the  total  transmission.  This  is  seen  in  Figure  25,  which  compares 
the  correlated  transmission  calculated  for  the  combined  system  with  the  uncorrelated  product 
of  the  transmissions  for  the  separate  atmosphere  and  clouds.  CLDSIM  uses  the 
uncorrelated  method  of  combining  transmissions.  The  relative  error  of  this  method  can  be 
estimated  by  taking  the  ratio  of  the  two  types  of  transmission  calculations  as  is  done  in 
Figure  24.  This  figure  shows  that  neglecting  line  correlation  can  lead  to  overestimates  of 
transmission  loss  by  up  to  a  factor  of  30  (at  2.68  pm,  for  instance).  Of  course,  the  magnitude 
of  the  error  depends  upon  the  specifics  of  the  case. 

1 1  Km  Cloud  Case 


We  performed  a  similar  set  of  calculations  for  a  11  km  altitude  cloud,  such  as  was 
observed  in  the  A.D.  Little  data.  Figure  27  shows  the  results  of  the  transmission  calculations, 
while  Figure  28  shows  the  relative  error  involved  in  neglecting  line  correlation.  Note  that  in 
this  case  the  transmissions  are  much  larger  in  the  band  centers  as  should  be  expected  at 
the  higher  altitude  here.  Because  of  this,  the  error  is  much  smaller,  e.g.,  a  factor  of  3. 

Conclusions 


The  calculations  described  above  indicate  that  neglect  of  line  correlation  can  lead  to 
overestimates  of  transmission  loss  by  up  to  a  factor  of  30  in  middle  level  clouds  (5  km)  and 
a  factor  of  3  for  high  level  clouds.  The  band-averaged  differences  ranged  from  over  a  factor 
of  2  to  slightly  less  than  50  %.  These  figures  should  not  be  taken  as  definitive,  since  (a)  they 
refer  to  two  specific  cases  and  (b)  the  model  was  as  simple  as  we  could  make  it.  However, 
the  calculations  are  consistent  with  the  idea  that  discrepancies  between  the  A.D.  Little  data 
and  the  CLDSIM  calculations  shown  in  Figure  22  can  be  attributed  to  CLDSIM’s  neglect  of 
the  line  correlation  between  the  atmospheric  path  and  cloud  vapor  transmissions. 
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TEMPERATURE  (K) 


Figure  23.  Atmospheric  Profiles  for  the  5  km  cloud  case 


2Ja  2.7  ZJS  zs 

WAVELENGTH  (p) 


Figure  24.  Calculations  of  the  transmission  in  the  cloud  (CLD),  in  the  atmosphere  only 
(ATM),  and  in  the  atmosphere  plus  cloud  (ATM+CLD) 


Figure  25.  Comparison  of  the  correlated  transmission  calculation  (<  ATM+CLD>) 
with  an  uncorrelated  product  calculation  (<ATM>  x  <CLD>). 


Figure  26.  Relative  error  in  using  the  product  of  the  atmospheric  and  cloud  transmissions 
rather  than  the  combined  atmosphere-cloud  transmission 
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Figure  27.  Calculations  of  the  transmission  in  the  cloud  (CLD),  in  the  atmosphere  only 
(ATM),  and  in  the  atmosphere  plus  cloud  (ATM+CLD) 


Figure  28.  Relative  error  in  using  the  product  of  the  atmospheric  and  cloud 
transmissions  rather  than  the  combined  atmosphere-cloud  transmission. 
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5.  CONCLUSIONS  AND  RECOMMENDATIONS 


Throughout  the  course  of  the  CLDSIM  review,  the  high  quality  of  PRA's  work  has  been 
evident.  The  extent  to  which  PRA  has  taken  pains  to  validate  CLDSIM  is  especially 
commendable.  However,  a  few  general  comments  can  be  made  about  CLDSIM.  They  are 
followed  by  more  specific  recommendations. 

CLDSIM  has  been  used  in  the  past  to  simulate  radiances  seen  by  high  altitude  strategic 
surveillance  sensors  observing  large  regions  at  moderate  spatial  resolution.  More  recently, 
it  is  being  used  to  model  returns  for  high-resolution  theater  scenarios.  To  accommodate  this 
new  mission,  some  of  the  assumptions  made  in  the  CLDSIM  model  should  be  modified.  For 
instance,  CLDSIM's  shadowing  treatments  should  be  updated  to  improve  cloud-to-cloud 
interactions.  In  addition,  scattering  off  of  smaller  cloud  features  should  be  enhanced  by  new 
methods  of  treating  small  optical  depth  BRDFs. 

CLDSIM  has  also  evolved  from  a  stand-alone  tool  used  primarily  by  PRA  personnel  to  a 
code  readily  available  to  the  defense  community  through  the  SSGM.  CLDSIM  should  be 
changed  in  at  least  two  ways  to  better  reflect  this  evolution.  First,  it  presently  has  an 
architecture  that  sequentially  processes  whole  databases,  calculating  surface  normals  on  the 
first  sweep  through  the  database,  scattering  angles  on  the  second,  and  radiances  on  the 
third.  CLDSIM  saves  the  results  from  each  sweep.  This  architecture  is  an  advantage  in  a 
stand-alone  code  where  these  intermediate  results  can  be  reused  in  slightly  altered  runs. 
For  instance,  a  scattering  angle  file  can  be  shared  between  two  runs  where  only  the 
assumed  model  atmosphere  has  changed.  The  saved  intermediate  results  have  little  utility 
in  the  SSGM  and  in  fact  slow  down  its  operation.  A  better  architecture  would  be  one  that 
performs  complete  calculations  on  each  pixel  before  moving  to  the  next  pixel,  and  one  that 
processes  only  those  pixels  in  the  FOV. 

The  move  from  a  stand-alone  code  to  the  SSGM  has  placed  CLDSIM  in  the  hands  of  less 
sophisticated  users.  Increased  error  checking  should  be  added  to  CLDSIM  to  make  sure  that 
the  complex  mix  of  clouds,  atmospheres  and  locations  that  go  into  a  CLDSIM  run  are 
physically  consistent.  In  addition,  more  information  should  be  given  about  the  meteorology 
represented  in  CLDSIM's  clouds  to  help  the  user  run  the  code  in  an  intelligent  manner. 

Cloud  Databases 


1)  The  techniques  used  to  spatially  interpolate  databases  to  finer  resolution  should  be 
validated. 
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2)  Methods  to  generate  synthetic  cloud  altitude  maps  with  realistic  structure  should  be 
developed  to  supplement  the  cloud  databases  constructed  from  data. 

3)  Data  should  be  collected  on  the  range  of  returns  seen  by  an  operational  sensor,  for  use 
in  developing  a  metric  whereby  the  structure  in  CLDSIM  scenes  could  be  classified  as 
stressing  or  benign. 

4)  Sources  of  stereoscopic  measurements  of  cloud  altitudes  and  other  techniques  should 
be  investigated  to  supplement  or  validate  CLDSIM’s  predictions  of  clutter  from  the  sides 
of  clouds  with  large  vertical  development.  The  proposed  RAMOS  experiment  could 
supply  such  measurements. 

5)  As  PRA  suggested,  scattering  clutter  attributable  to  variations  in  Liquid  Water  Content 
(LWC)  across  a  cloud  should  be  added  to  CLDSIM  if  measurements  of  LWC  can  be 
extracted  from  the  data,  and  BRDFs  with  varying  LWC  are  added  as  well. 

Note:  PRA  is  planning  an  increased  number  of  30-120  m  resolution  databases  for  future 

releases  of  the  SSGM.  Low  resolution  global  databases  are  planned  as  well. 

BRDFs 

1 )  Correlated  line  transmission  between  a  cloud  and  the  surrounding  atmosphere  should  be 
incorporated  into  CLDSIM. 

2)  The  variety  of  cloud  types  available  in  the  SSGM  should  be  increased  by  adding  more 
BRDFs,  or  by  generating  them  on-line. 

3)  Methods  of  quickly  approximating  BRDFs  should  be  developed  to  allow  for  modeling  of 
complex  scattering  patterns  in  optically  thin  clouds,  and  other  variations  due  to  changes 
in  microphysical  properties  of  clouds. 

4)  If  quick,  online  calculation  of  BRDFs  is  not  implemented,  CLDSIM's  opacity  weighting  of 
the  BRDF  to  account  for  thin  clouds  should  be  replaced  with  an  interpolation  between  the 
single  scattering  result  and  the  optically  thick  result: 

=[  Pb0  (''Large)  --5  Large)]  +5(t) 

5)  Higher  angular  resolution  should  be  used  in  CLDSIM  to  better  capture  BRDF  variations 
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in  optically  thin  clouds. 


6)  New  BRDFs  should  be  validated  against  aircraft  measurements  where  available. 

Note:  PRA  is  planning  improvements  to  the  cloud  droplet  distributions,  higher  spectral  and 

angular  resolution,  and  two  new  cloud  types  for  future  releases  of  the  SSGM. 

CLDSIM  Calculational  Steps 

1 )  Shadowing  of  cloud  pixels  from  the  sun  should  include  obscuration  by  distance  surfaces 
and  not  depend  just  on  the  pixel's  local  orientation. 

2)  Illumination  of  cloud  pixels  by  other  cloud  surfaces  should  be  added  in  more  than  a 
diffuse  manner.  Multiple  resolution  renderings  of  the  cloud  surface  may  be  appropriate 
for  this  task. 

3)  Back  illumination  of  cloud  surfaces  and  multiple  scattering  in  non-slab  geometries  should 
be  included  for  clouds  with  radii  of  curvature  small  compared  to  scattering  mean  free 
paths. 

4)  Beam  transmission  of  terrain  backgrounds  through  clouds  should  be  modified  to  include 
forward  scattering  enhancements. 

5)  The  smearing  of  terrain  clutter  upon  passing  through  clouds  should  be  modeled  by 
modulating  the  terrain  clutter  in  CLDSIM. 

6)  Sources  of  atmospheric  clutter  should  be  incorporated  into  CLDSIM  as  they  become 
available  in  standard  atmospheric  codes. 

Note:  PRA  is  planning  to  replace  pixels  with  triangular  facets  to  improve  cloud  shadowing. 

They  are  planning  upgrades  to  CLDSIM's  footprinting  routines.  They  are  also  planning  three- 

stream  cloud-over-cloud  and  cloud-over-terrain  models  for  future  releases  of  the  SSGM 

CLDSIM  as  Hosted  in  the  SSGM 


1 )  More  information  about  the  meterology  behind  the  cloud  databases  should  be  provided 
to  the  SSGM  user  to  aid  in  correctly  positioning  them. 


54 


2)  More  robust  error  checking  should  be  applied  to  CLDSIM  inputs  to  insure  correct 
atmospheric  profiles  and  cloud  types  for  a  given  scenario. 

3)  Changes  should  be  made  in  the  CLDSIM  architecture  so  that  only  pixels  in  the  FOV  are 
processed. 

Note:  PRA  is  reorganizing  CLDSIM  for  speed  and  will  at  some  point  include  a  "cookie  cutter" 
model  to  allow  one  to  trim  cloud  databases  for  specific  applications. 
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